Stupid NVIDIA 3D vgaarb.c patch

[Pasi Kärkkäinen]

On Mon, Sep 22, 2014 at 06:10:50PM -0400, Alex Deucher wrote:
> >
> > With dual VGA controllers, we can change VGA routing in the chipset so
> > that we can address one device or the other using the VGA address space.
> > This lets things like Xorg switch between cards to initialize a card via
> > the VGA BIOS or execute runtime VGA BIOS calls.  If one of those devices
> > reports itself as a 3D controller, then we have no reason to believe
> > that the device actually responds to VGA accesses or that the PCI ROM
> > payload includes a VGA BIOS.
> >
> > Maybe that's how the arbiter device registration should work, if the
> > class code is VGA add it, if it's 3D controller, switch VGA routing and
> > see if it responds to VGA.  There are still a couple problems that I've
> > been beating my head against though.  First, i915 lies when it opts-out
> > of VGA arbitration, so you might think you've found a VGA device
> > elsewhere, but you're actually still talking to IGD.  Second is the Xorg
> > DRI problem where it's going to disable DRI support if suddenly a second
> > arbitration participant appears.  This is what happened when I tried to
> > fix the i915 problem and suddenly anybody with IGD + plugin graphics
> > lost DRI and the fix was reverted.  The whole thing is pretty broken.
> >
> > In this case, if your laptop actually supports disabling and hiding the
> > IGD device, I'd expect the Nvidia device to switch to reporting itself
> > as VGA.  It seems like often the Optimus graphics aren't even directly
> > connected to an output device, which makes me curious that you can
> > actually pick one or the other.  Thanks,
> 
> AFAIK, on most recent (like in the last 2-3 years) hybrid laptops
> don't really have the option to boot to the dGPU or even disable the
> integrated graphics (I'm not sure that was ever possibly, even on the
> old muxed ones).  Depending on the OEM, the dGPU may be wired to one
> or more of the external ports, but I don't think those are usable
> until after the drivers have loaded.  Newer radeon PowerXpress laptops
> mark the dGPU as PCI_CLASS_DISPLAY_OTHER and I don't think there is
> any expectation that they should be messing with vga.
>

I had Lenovo T430 hybrid graphics laptop earlier, which is in "last 2-3 years",
and it allowed me to choose "IGD only", "Optimus", or "Nvidia only" in BIOS..


-- Pasi

> Alex
> 

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Fri, Oct 18, 2013 at 05:44:45PM +0300, Pasi K?rkk?inen wrote:
> On Thu, Sep 26, 2013 at 02:48:49AM +1000, Ben Skeggs wrote:
> > >
> > > Ben/Maarten: Are you guys planning to take a look at this and submit 
> > > another patch, or.. ?
> > >
> > > I tested the two earlier patches from this thread, and they both fixed 
> > > the problem (hard kernel crash).
> > > I'm hoping this bug could be finally solved in the kernel..
> >
> > I shall be looking at it properly once I'm back from XDC next week.
> > 
> 
> Any thoughts about the patch? 
> 
>

Ben: ping again? 

This nouveau bug is still causing hard kernel crashes out there..
recent bug report against Fedora 20: 
https://bugzilla.redhat.com/show_bug.cgi?id=1047169

Thanks,

-- Pasi

> 
> > Thanks,
> > Ben.
> > 

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Wed, Sep 25, 2013 at 05:42:46PM +0300, Pasi K?rkk?inen wrote:
> On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> > 
> > When looking into this bug I noticed that nouveau_bo_vma_add needs to have 
> > a check for nvbo->page_shift == vma->vm->vmm->spg_shift,
> > and only if the check is true it should map the page in TTM_PL_TT. Patch 
> > below.
> > Should probably also be cc'd to stable.
> >
> 
> How about this patch? Is it ready to go in? 
>

Ping on this patch aswell..


-- Pasi


> Thanks,
> 
> -- Pasi
> 
>  
> > ~Maarten
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 89b992e..355a1b7 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
> > nouveau_vm *vm,
> >  
> > if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
> > nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> > -   else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> > +   else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
> > +nvbo->page_shift == vma->vm->vmm->spg_shift) {
> > if (node->sg)
> > nouveau_vm_map_sg_table(vma, 0, size, node);
> > else
> > 

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Sep 26, 2013 at 02:48:49AM +1000, Ben Skeggs wrote:
> >
> > Ben/Maarten: Are you guys planning to take a look at this and submit 
> > another patch, or.. ?
> >
> > I tested the two earlier patches from this thread, and they both fixed the 
> > problem (hard kernel crash).
> > I'm hoping this bug could be finally solved in the kernel..
>
> I shall be looking at it properly once I'm back from XDC next week.
> 

Any thoughts about the patch? 


-- Pasi

> Thanks,
> Ben.
> 
> >
> > Thanks,
> >
> > -- Pasi
> >

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Sep 26, 2013 at 02:48:49AM +1000, Ben Skeggs wrote:
> On Thu, Sep 26, 2013 at 12:41 AM, Pasi Kärkkäinen  wrote:
> > Hello,
> >
> > On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> >> Op 04-09-13 05:41, Ben Skeggs schreef:
> >> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> >> >  wrote:
> >> >> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >> >>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >> >>> set, it will do a null deref down the line. Warn on that condition and
> >> >>> return an error.
> >> >>>
> >> >>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >> >>>
> >> >>> Reported-by: Pasi Kärkkäinen 
> >> >>> Tested-by: Pasi Kärkkäinen 
> >> >>> Signed-off-by: Ilia Mirkin 
> >> >>> Cc:  # 3.8+
> >> >>> ---
> >> >>>
> >> >>> I don't exactly understand what's going on, but this is just a
> >> >>> straightforward way to avoid a null deref that you see happens in the
> >> >>> bug. I haven't figured out the root cause of this, but it's getting
> >> >>> well into the "I have no idea how TTM works" space. However this seems
> >> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >> >>> node->pages as a list down, which will be dereferenced by
> >> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >> >>> dereferencing not happen, but it definitely was happening here, as you
> >> >>> can see in the bug.
> >> >>>
> >> >>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >> >>> since like I hope I was able to convey above, I'm just not really sure 
> >> >>> :)
> >> >> 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...
> >> >>
> >> >> 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;
> >> >> +   }
> >> >> +
> >> > Definitely the right idea, we can't handle this case right now.
> >> > However, we may someday want/need to be able to scan out of system
> >> > memory, so this is the wrong place.
> >> >
> >> > I suspect the correct thing to do (which'll also handle the
> >> > "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> >> > a DMA-BUF backed object into VRAM.
> >> >
> >> > Sound OK?
> >> >
> >> If it has a WARN_ON or something that would be ok, I didn't find any other 
> >> places that attempt to move buffers to VRAM though, so it's probably 
> >> harmless.
> >>
> >
> > Ben/Maarten: Are you guys planning to take a look at this and submit 
> > another patch, or.. ?
> >
> > I tested the two earlier patches from this thread, and they both fixed the 
> > problem (hard kernel crash).
> > I'm hoping this bug could be finally solved in the kernel..
> I shall be looking at it properly once I'm back from XDC next week.
> 

Great, thanks!


-- Pasi

> Thanks,
> Ben.
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> 
> When looking into this bug I noticed that nouveau_bo_vma_add needs to have a 
> check for nvbo->page_shift == vma->vm->vmm->spg_shift,
> and only if the check is true it should map the page in TTM_PL_TT. Patch 
> below.
> Should probably also be cc'd to stable.
>

How about this patch? Is it ready to go in? 

Thanks,

-- Pasi

 
> ~Maarten
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 89b992e..355a1b7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
> nouveau_vm *vm,
>  
>   if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
>   nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> - else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> + else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
> +  nvbo->page_shift == vma->vm->vmm->spg_shift) {
>   if (node->sg)
>   nouveau_vm_map_sg_table(vma, 0, size, node);
>   else
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

Hello,

On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> Op 04-09-13 05:41, Ben Skeggs schreef:
> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> >  wrote:
> >> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >>> set, it will do a null deref down the line. Warn on that condition and
> >>> return an error.
> >>>
> >>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >>>
> >>> Reported-by: Pasi Kärkkäinen 
> >>> Tested-by: Pasi Kärkkäinen 
> >>> Signed-off-by: Ilia Mirkin 
> >>> Cc:  # 3.8+
> >>> ---
> >>>
> >>> I don't exactly understand what's going on, but this is just a
> >>> straightforward way to avoid a null deref that you see happens in the
> >>> bug. I haven't figured out the root cause of this, but it's getting
> >>> well into the "I have no idea how TTM works" space. However this seems
> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >>> node->pages as a list down, which will be dereferenced by
> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >>> dereferencing not happen, but it definitely was happening here, as you
> >>> can see in the bug.
> >>>
> >>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >>> since like I hope I was able to convey above, I'm just not really sure :)
> >> 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...
> >>
> >> 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;
> >> +   }
> >> +
> > Definitely the right idea, we can't handle this case right now.
> > However, we may someday want/need to be able to scan out of system
> > memory, so this is the wrong place.
> >
> > I suspect the correct thing to do (which'll also handle the
> > "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> > a DMA-BUF backed object into VRAM.
> >
> > Sound OK?
> >
> If it has a WARN_ON or something that would be ok, I didn't find any other 
> places that attempt to move buffers to VRAM though, so it's probably harmless.
>

Ben/Maarten: Are you guys planning to take a look at this and submit another 
patch, or.. ? 

I tested the two earlier patches from this thread, and they both fixed the 
problem (hard kernel crash).
I'm hoping this bug could be finally solved in the kernel..

Thanks,

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> Op 04-09-13 05:41, Ben Skeggs schreef:
> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> >  wrote:
> >> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >>> set, it will do a null deref down the line. Warn on that condition and
> >>> return an error.
> >>>
> >>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >>>
> >>> Reported-by: Pasi Kärkkäinen 
> >>> Tested-by: Pasi Kärkkäinen 
> >>> Signed-off-by: Ilia Mirkin 
> >>> Cc:  # 3.8+
> >>> ---
> >>>
> >>> I don't exactly understand what's going on, but this is just a
> >>> straightforward way to avoid a null deref that you see happens in the
> >>> bug. I haven't figured out the root cause of this, but it's getting
> >>> well into the "I have no idea how TTM works" space. However this seems
> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >>> node->pages as a list down, which will be dereferenced by
> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >>> dereferencing not happen, but it definitely was happening here, as you
> >>> can see in the bug.
> >>>
> >>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >>> since like I hope I was able to convey above, I'm just not really sure :)
> >> 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...
> >>
> >> 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;
> >> +   }
> >> +
> > Definitely the right idea, we can't handle this case right now.
> > However, we may someday want/need to be able to scan out of system
> > memory, so this is the wrong place.
> >
> > I suspect the correct thing to do (which'll also handle the
> > "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> > a DMA-BUF backed object into VRAM.
> >
> > Sound OK?
> >
> If it has a WARN_ON or something that would be ok, I didn't find any other 
> places that attempt to move buffers to VRAM though, so it's probably harmless.
> 

So hmm.. I guess another patch is needed for the original issue in this thread.
Is someone going to submit that? 


> When looking into this bug I noticed that nouveau_bo_vma_add needs to have a 
> check for nvbo->page_shift == vma->vm->vmm->spg_shift,
> and only if the check is true it should map the page in TTM_PL_TT. Patch 
> below.
> Should probably also be cc'd to stable.
>

Thanks! Is this patch ready to be merged?


-- Pasi
 

> ~Maarten
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 89b992e..355a1b7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
> nouveau_vm *vm,
>  
>   if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
>   nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> - else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> + else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
> +  nvbo->page_shift == vma->vm->vmm->spg_shift) {
>   if (node->sg)
>   nouveau_vm_map_sg_table(vma, 0, size, node);
>   else
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

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=0004
> > >>>>
> > >>>> 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

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Tue, Sep 03, 2013 at 04:34:56PM +0200, Maarten Lankhorst wrote:
> Op 03-09-13 16:20, Pasi Kärkkäinen schreef:
> > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote:
> >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
> >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
> >>>> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> >>>>> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >>>>>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >>>>>> set, it will do a null deref down the line. Warn on that condition and
> >>>>>> return an error.
> >>>>>>
> >>>>>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >>>>>>
> >>>>>> Reported-by: Pasi Kärkkäinen 
> >>>>>> Tested-by: Pasi Kärkkäinen 
> >>>>>> Signed-off-by: Ilia Mirkin 
> >>>>>> Cc:  # 3.8+
> >>>>>> ---
> >>>>>>
> >>>>>> I don't exactly understand what's going on, but this is just a
> >>>>>> straightforward way to avoid a null deref that you see happens in the
> >>>>>> bug. I haven't figured out the root cause of this, but it's getting
> >>>>>> well into the "I have no idea how TTM works" space. However this seems
> >>>>>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >>>>>> node->pages as a list down, which will be dereferenced by
> >>>>>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >>>>>> dereferencing not happen, but it definitely was happening here, as you
> >>>>>> can see in the bug.
> >>>>>>
> >>>>>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >>>>>> since like I hope I was able to convey above, I'm just not really sure 
> >>>>>> :)
> >>>>> 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=0004
> >>>>
> >>>> 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?

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote:
> Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
> > On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
> >> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> >>> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >>>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >>>> set, it will do a null deref down the line. Warn on that condition and
> >>>> return an error.
> >>>>
> >>>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >>>>
> >>>> Reported-by: Pasi Kärkkäinen 
> >>>> Tested-by: Pasi Kärkkäinen 
> >>>> Signed-off-by: Ilia Mirkin 
> >>>> Cc:  # 3.8+
> >>>> ---
> >>>>
> >>>> I don't exactly understand what's going on, but this is just a
> >>>> straightforward way to avoid a null deref that you see happens in the
> >>>> bug. I haven't figured out the root cause of this, but it's getting
> >>>> well into the "I have no idea how TTM works" space. However this seems
> >>>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >>>> node->pages as a list down, which will be dereferenced by
> >>>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >>>> dereferencing not happen, but it definitely was happening here, as you
> >>>> can see in the bug.
> >>>>
> >>>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >>>> since like I hope I was able to convey above, I'm just not really sure :)
> >>> 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=0004
> >>
> >> 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)

All comments welcome.

Thanks,

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi K?rkk?inen wrote:
> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> > Op 22-08-13 02:10, Ilia Mirkin schreef:
> > > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > > set, it will do a null deref down the line. Warn on that condition and
> > > return an error.
> > >
> > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> > >
> > > Reported-by: Pasi K?rkk?inen 
> > > Tested-by: Pasi K?rkk?inen 
> > > Signed-off-by: Ilia Mirkin 
> > > Cc:  # 3.8+
> > > ---
> > >
> > > I don't exactly understand what's going on, but this is just a
> > > straightforward way to avoid a null deref that you see happens in the
> > > bug. I haven't figured out the root cause of this, but it's getting
> > > well into the "I have no idea how TTM works" space. However this seems
> > > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > > node->pages as a list down, which will be dereferenced by
> > > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > > dereferencing not happen, but it definitely was happening here, as you
> > > can see in the bug.
> > >
> > > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > > since like I hope I was able to convey above, I'm just not really sure :)
> > 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=0004
> 
> 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 ? 

-- Pasi


> --- 
> linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c.orig   
> 2013-07-01 01:13:29.0 +0300
> +++ linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c
> 2013-08-23 19:56:52.038234281 +0300
> @@ -137,18 +137,31 @@
>  {
>   struct nouveau_framebuffer *nouveau_fb;
>   struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
>   int ret;
>  
>   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;
> + drm_gem_object_unreference(gem);
> + return ERR_PTR(ret);
> + }
> +
>   nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> - if (!nouveau_fb)
> + if (!nouveau_fb) {
> + drm_gem_object_unreference(gem);
>   return ERR_PTR(-ENOMEM);
> + }
>  
> - 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) {
> + kfree(nouveau_fb);
>   drm_gem_object_unreference(gem);
>   return ERR_PTR(ret);
>   }

> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> > Op 22-08-13 02:10, Ilia Mirkin schreef:
> > > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > > set, it will do a null deref down the line. Warn on that condition and
> > > return an error.
> > >
> > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> > >
> > > Reported-by: Pasi Kärkkäinen 
> > > Tested-by: Pasi Kärkkäinen 
> > > Signed-off-by: Ilia Mirkin 
> > > Cc:  # 3.8+
> > > ---
> > >
> > > I don't exactly understand what's going on, but this is just a
> > > straightforward way to avoid a null deref that you see happens in the
> > > bug. I haven't figured out the root cause of this, but it's getting
> > > well into the "I have no idea how TTM works" space. However this seems
> > > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > > node->pages as a list down, which will be dereferenced by
> > > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > > dereferencing not happen, but it definitely was happening here, as you
> > > can see in the bug.
> > >
> > > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > > since like I hope I was able to convey above, I'm just not really sure :)
> > 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=0004
> 
> 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 ? 
 
-- Pasi


> --- 
> linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c.orig   
> 2013-07-01 01:13:29.0 +0300
> +++ linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c
> 2013-08-23 19:56:52.038234281 +0300
> @@ -137,18 +137,31 @@
>  {
>   struct nouveau_framebuffer *nouveau_fb;
>   struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
>   int ret;
>  
>   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;
> + drm_gem_object_unreference(gem);
> + return ERR_PTR(ret);
> + }
> +
>   nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> - if (!nouveau_fb)
> + if (!nouveau_fb) {
> + drm_gem_object_unreference(gem);
>   return ERR_PTR(-ENOMEM);
> + }
>  
> - 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) {
> + kfree(nouveau_fb);
>   drm_gem_object_unreference(gem);
>   return ERR_PTR(ret);
>   }

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi K?rkk?inen 
> > Tested-by: Pasi K?rkk?inen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> 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=0004

Does that help? 


-- Pasi

-- next part --
A non-text attachment was scrubbed...
Name: nouveau_test_fix_null_deref_v3.10.patch
Type: text/x-diff
Size: 1202 bytes
Desc: not available
URL: 

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi Kärkkäinen 
> > Tested-by: Pasi Kärkkäinen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> 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=0004

Does that help? 


-- Pasi

--- linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c.orig	2013-07-01 01:13:29.0 +0300
+++ linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c	2013-08-23 19:56:52.038234281 +0300
@@ -137,18 +137,31 @@
 {
 	struct nouveau_framebuffer *nouveau_fb;
 	struct drm_gem_object *gem;
+	struct nouveau_bo *nvbo;
 	int ret;
 
 	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;
+		drm_gem_object_unreference(gem);
+		return ERR_PTR(ret);
+	}
+
 	nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
-	if (!nouveau_fb)
+	if (!nouveau_fb) {
+		drm_gem_object_unreference(gem);
 		return ERR_PTR(-ENOMEM);
+	}
 
-	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) {
+		kfree(nouveau_fb);
 		drm_gem_object_unreference(gem);
 		return ERR_PTR(ret);
 	}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi K?rkk?inen 
> > Tested-by: Pasi K?rkk?inen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> 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...
>

Thanks! I'll give it a try later today.. 


-- 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 04:41:06PM +1000, Ben Skeggs wrote:
> On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin  wrote:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi K?rkk?inen 
> > Tested-by: Pasi K?rkk?inen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> >
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index cdc3282..191145d 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -963,6 +963,12 @@ nouveau_vma_getmap(struct nouveau_channel *chan, 
> > struct nouveau_bo *nvbo,
> > struct nouveau_mem *node = mem->mm_node;
> > int ret;
> >
> > +   /* If we ever get here for a non-vram mem node that doesn't
> > +* have pages, we will end up doing a null deref in
> > +* nouveau_vm_map_sg. */
> > +   if (WARN_ON(mem->mem_type != TTM_PL_VRAM && !node->pages))
> > +   return -EINVAL;
> My guess here is that this is a mapping that requires the use of
> map_sg_table() (see nouveau_bo_move_ntfy() for the condition).
> 
> I'm not entirely sure this should even be happening to be honest.  I
> guess TTM is trying to move a shared buffer from GART to VRAM for some
> reason (userspace probably asked for it?).. And well, this really
> shouldn't be allowed.. The other device won't be able to touch it
> then.
> 
> If you can confirm this is indeed what's happening, we should find out
> why and fix it (and have the kernel completely reject such attempts).
>

Yes it does happen. I've been experiencing the kernel crash with Linux 3.8.x, 
3.9.x and 3.10.x.

I'm able to reproduce the crash when having Optimus enabled in BIOS on my 
Lenovo T430 laptop with Intel IGD + Nvidia GF108 GPU, booting to Xorg desktop, 
and when I try to enable external DVI monitor connected to nouveau card, the 
kernel crashes hard.. 

crash traceback and WARN_ON() tracebacks with this patch applied available in 
the bugzilla entry: 
https://bugs.freedesktop.org/show_bug.cgi?id=64774


-- Pasi


> Ben.
> 
> > +
> > ret = nouveau_vm_get(nv_client(chan->cli)->vm, mem->num_pages <<
> >  PAGE_SHIFT, node->page_shift,
> >  NV_MEM_ACCESS_RW, vma);
> > --
> > 1.8.1.5
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi Kärkkäinen 
> > Tested-by: Pasi Kärkkäinen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> 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...
>

Thanks! I'll give it a try later today.. 


-- 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Thu, Aug 22, 2013 at 04:41:06PM +1000, Ben Skeggs wrote:
> On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin  wrote:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >
> > Reported-by: Pasi Kärkkäinen 
> > Tested-by: Pasi Kärkkäinen 
> > Signed-off-by: Ilia Mirkin 
> > Cc:  # 3.8+
> > ---
> >
> > I don't exactly understand what's going on, but this is just a
> > straightforward way to avoid a null deref that you see happens in the
> > bug. I haven't figured out the root cause of this, but it's getting
> > well into the "I have no idea how TTM works" space. However this seems
> > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > node->pages as a list down, which will be dereferenced by
> > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > dereferencing not happen, but it definitely was happening here, as you
> > can see in the bug.
> >
> > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > since like I hope I was able to convey above, I'm just not really sure :)
> >
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index cdc3282..191145d 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -963,6 +963,12 @@ nouveau_vma_getmap(struct nouveau_channel *chan, 
> > struct nouveau_bo *nvbo,
> > struct nouveau_mem *node = mem->mm_node;
> > int ret;
> >
> > +   /* If we ever get here for a non-vram mem node that doesn't
> > +* have pages, we will end up doing a null deref in
> > +* nouveau_vm_map_sg. */
> > +   if (WARN_ON(mem->mem_type != TTM_PL_VRAM && !node->pages))
> > +   return -EINVAL;
> My guess here is that this is a mapping that requires the use of
> map_sg_table() (see nouveau_bo_move_ntfy() for the condition).
> 
> I'm not entirely sure this should even be happening to be honest.  I
> guess TTM is trying to move a shared buffer from GART to VRAM for some
> reason (userspace probably asked for it?).. And well, this really
> shouldn't be allowed.. The other device won't be able to touch it
> then.
> 
> If you can confirm this is indeed what's happening, we should find out
> why and fix it (and have the kernel completely reject such attempts).
>

Yes it does happen. I've been experiencing the kernel crash with Linux 3.8.x, 
3.9.x and 3.10.x.

I'm able to reproduce the crash when having Optimus enabled in BIOS on my 
Lenovo T430 laptop with Intel IGD + Nvidia GF108 GPU, booting to Xorg desktop, 
and when I try to enable external DVI monitor connected to nouveau card, the 
kernel crashes hard.. 

crash traceback and WARN_ON() tracebacks with this patch applied available in 
the bugzilla entry: 
https://bugs.freedesktop.org/show_bug.cgi?id=64774


-- Pasi


> Ben.
> 
> > +
> > ret = nouveau_vm_get(nv_client(chan->cli)->vm, mem->num_pages <<
> >  PAGE_SHIFT, node->page_shift,
> >  NV_MEM_ACCESS_RW, vma);
> > --
> > 1.8.1.5
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] [RFC] drm/nouveau: bring back hdmi audio device after switcheroo power down

[Pasi Kärkkäinen]

On Wed, Jul 24, 2013 at 05:13:42PM +1000, Dave Airlie wrote:
> After a full device powerdown via the optimus power switch, we seem
> to lose the HDMI device completely on power on, this keep track of
> whether we had a hdmi audio sub function device at power on, and
> pokes a magic register to make it reappear after the optimus power
> switch is thrown.
> 
> This at least works on my NVC4 machine, probably needs testing on
> a few other laptops with other nvidia GPUs.
> 

Sorry for a stupid question, but how do you test "optimus power switch" ? 
(I have a laptop with hybrid Optimus graphics, so I could test..)

Thanks,

-- Pasi 

Re: [PATCH] [RFC] drm/nouveau: bring back hdmi audio device after switcheroo power down

[Pasi Kärkkäinen]

On Wed, Jul 24, 2013 at 05:13:42PM +1000, Dave Airlie wrote:
> After a full device powerdown via the optimus power switch, we seem
> to lose the HDMI device completely on power on, this keep track of
> whether we had a hdmi audio sub function device at power on, and
> pokes a magic register to make it reappear after the optimus power
> switch is thrown.
> 
> This at least works on my NVC4 machine, probably needs testing on
> a few other laptops with other nvidia GPUs.
> 

Sorry for a stupid question, but how do you test "optimus power switch" ? 
(I have a laptop with hybrid Optimus graphics, so I could test..)

Thanks,

-- Pasi 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

nouveau GF108 kernel crash in optimus mode when enabling external display output

[Pasi Kärkkäinen]

On Thu, May 09, 2013 at 06:11:23PM +0300, Pasi K?rkk?inen wrote:
> Hello,
> 
> ping also here.. any other information needed about this nouveau kernel 
> crash? 
>

So this hard kernel crash stil happens with Linux 3.9.2,
with the difference that I don't get to see the traceback with 3.9.2.

(with 3.8.x kernels I can see the crash errors/traceback on the console).

-- Pasi

> 
> On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi K?rkk?inen wrote:
> > Hello,
> > 
> > Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in 
> > BIOS:
> > 
> > $ lspci | grep VGA
> > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
> > Graphics Controller (rev 09)
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> > 5400M] (rev a1)
> > 
> > $ uname -a
> > Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 
> > 19:44:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> > 
> > I boot up the system with only laptop internal LVDS active on intel gpu, 
> > and when in X session,
> > I enable the second display on nouveau gpu connected to the dock DP2/DVI 
> > connector.
> > At this point the kernel crashes immediately. 
> > 
> > Screenshots of the kernel crash/stacktrace here:
> > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg
> > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg
> > 
> > hand-written bits from the kernel crash:
> > 
> > Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 
> > 2349H2G/2349H2G
> > RIP: 0010:[] [] 
> > nvc0_vm_map_sg+0x8e/0x110 [nouveau]
> > RSP: 0018:8803298357c8 EFLAGS: 00010206
> > ..
> > Process Xorg (pid: 1208,..)
> > ..
> > Call Trace:
> > .. nouveau_vm_map_sg+0xc2/0x130 [nouveau]
> > .. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau]
> > .. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau]
> > .. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau]
> > .. nouveau_bo_move+0xa5/0x400 [nouveau]
> > .. ttm_bo_handle_move_mem+0x245/0x610 [ttm]
> > 
> > More info from the screenshots above.. 
> > 
> > 
> > dmesg drm bits before the crash:
> > 
> > [0.137586] vgaarb: device added: 
> > PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
> > [0.137590] vgaarb: device added: 
> > PCI::01:00.0,decodes=io+mem,owns=none,locks=none
> > [0.137591] vgaarb: loaded
> > [0.137591] vgaarb: bridge control possible :01:00.0
> > [0.137592] vgaarb: no bridge control possible :00:02.0
> > [0.529802] fb0: VESA VGA frame buffer device
> > [0.877212] ata1.00: supports DRM functions and may not be fully 
> > accessible
> > [0.878010] ata1.00: supports DRM functions and may not be fully 
> > accessible
> > [1.969486] [drm] Initialized drm 1.1.0 20060810
> > [1.990584] VGA switcheroo: detected Optimus DSM method 
> > \_SB_.PCI0.PEG_.VID_ handle
> > [1.990610] nouveau :01:00.0: enabling device (0004 -> 0007)
> > [1.990874] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
> > [1.990877] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
> > [1.990878] nouveau  [  DEVICE][:01:00.0] Family : NVC0
> > [1.992485] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for 
> > image...
> > [2.002182] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [2.002184] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> > [2.002243] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [2.002245] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> > [2.189928] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
> > [2.189935] nouveau  [   VBIOS][:01:00.0] using image from ACPI
> > [2.190143] nouveau  [   VBIOS][:01:00.0] BIT signature found
> > [2.190149] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
> > [2.190467] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
> > [2.190470] nouveau  [   VBIOS][:01:00.0] running init tables
> > [2.278184] nouveau  [ PFB][:01:00.0] RAM type: DDR3
> > [2.278189] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
> > [2.278192] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
> > [2.311802] nouveau  [ DRM] VRAM: 512 MiB
> > [2.311805] nouveau  [ DRM] GART: 512 MiB
> > [2.311810] nouveau  [ DRM] BIT BIOS found
> > [2.311814] nouveau  [ DRM] Bios version 70.08.b7.02
> > [2.311831] nouveau  [ DRM] TMDS table version 2.0
> > [2.311832] nouveau  [ DRM] DCB version 4.0
> > [2.311833] nouveau  [ DRM] DCB outp 00: 01800323 00010034
> > [2.311834] nouveau  [ DRM] DCB outp 01: 02811300 
> > [2.311835] nouveau  [ DRM] DCB outp 02: 028223a6 0f220010
> > [2.311836] nouveau  [ DRM] DCB outp 03: 02822362 00020010
> > [2.311837] nouveau  [ DRM] DCB outp 04: 048333b6 0f220010
> > [2.311838] nouveau  [ DRM] DCB outp 05: 04833372 00020010
> > [2.311839] nouveau  [ DRM] 

nouveau GF108 kernel errors and graphics corruption when enabling another output

[Pasi Kärkkäinen]

On Thu, May 09, 2013 at 06:10:04PM +0300, Pasi K?rkk?inen wrote:
> Hello,
> 
> Any comments? Should I provide more logs, or try something I didn't try yet? 
>

I just tried Linux kernel 3.9.2, and it has the same kind of graphics corruption
when enabling second output on nouveau adapter.

dmesg errors from 3.9.2:

[   91.533612] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
[   91.533618] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
[   91.533856] nouveau E[PBUS][:01:00.0] MMIO read of 0x FAULT 
at 0x141820 [ IBUS ]
[  246.466283] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  246.466287] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  246.499229] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  246.499232] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  246.522166] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  246.522169] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28


-- Pasi

> 
> On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi K?rkk?inen wrote:
> > Hello,
> > 
> > Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is 
> > disabled in BIOS,
> > and only the Nvidia discreet GPU is enabled:
> > 
> > $ lspci | grep VGA
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> > 5400M] (rev a1)
> > 
> > 
> > I boot up the laptop with only using the laptop internal LVDS panel, and 
> > when in X session,
> > I connect DVI cable to the docking station. xrandr now correctly shows DP2 
> > as connected,
> > and when I enable the DVI display, I get these nouveau errors in the kernel 
> > dmesg:
> > 
> > [  103.196252] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
> > [  103.196257] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
> > [  103.353160] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.353163] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.353923] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.353925] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.354257] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.354259] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.354703] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.354705] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.404091] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.404094] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.418076] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.418078] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.418567] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.418569] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.418788] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.418789] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.419164] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.419166] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.419473] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.419474] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.420080] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.420082] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.420367] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.420369] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.423674] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.423676] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.471348] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.471351] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.487327] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.487330] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.487675] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.487677] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.488222] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.488224] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.488834] nouvea

Re: nouveau GF108 kernel crash in optimus mode when enabling external display output

[Pasi Kärkkäinen]

On Thu, May 09, 2013 at 06:11:23PM +0300, Pasi Kärkkäinen wrote:
> Hello,
> 
> ping also here.. any other information needed about this nouveau kernel 
> crash? 
>

So this hard kernel crash stil happens with Linux 3.9.2,
with the difference that I don't get to see the traceback with 3.9.2.

(with 3.8.x kernels I can see the crash errors/traceback on the console).

-- Pasi

> 
> On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi Kärkkäinen wrote:
> > Hello,
> > 
> > Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in 
> > BIOS:
> > 
> > $ lspci | grep VGA
> > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
> > Graphics Controller (rev 09)
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> > 5400M] (rev a1)
> > 
> > $ uname -a
> > Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 
> > 19:44:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> > 
> > I boot up the system with only laptop internal LVDS active on intel gpu, 
> > and when in X session,
> > I enable the second display on nouveau gpu connected to the dock DP2/DVI 
> > connector.
> > At this point the kernel crashes immediately. 
> > 
> > Screenshots of the kernel crash/stacktrace here:
> > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg
> > http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg
> > 
> > hand-written bits from the kernel crash:
> > 
> > Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 
> > 2349H2G/2349H2G
> > RIP: 0010:[] [] 
> > nvc0_vm_map_sg+0x8e/0x110 [nouveau]
> > RSP: 0018:8803298357c8 EFLAGS: 00010206
> > ..
> > Process Xorg (pid: 1208,..)
> > ..
> > Call Trace:
> > .. nouveau_vm_map_sg+0xc2/0x130 [nouveau]
> > .. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau]
> > .. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau]
> > .. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau]
> > .. nouveau_bo_move+0xa5/0x400 [nouveau]
> > .. ttm_bo_handle_move_mem+0x245/0x610 [ttm]
> > 
> > More info from the screenshots above.. 
> > 
> > 
> > dmesg drm bits before the crash:
> > 
> > [0.137586] vgaarb: device added: 
> > PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
> > [0.137590] vgaarb: device added: 
> > PCI::01:00.0,decodes=io+mem,owns=none,locks=none
> > [0.137591] vgaarb: loaded
> > [0.137591] vgaarb: bridge control possible :01:00.0
> > [0.137592] vgaarb: no bridge control possible :00:02.0
> > [0.529802] fb0: VESA VGA frame buffer device
> > [0.877212] ata1.00: supports DRM functions and may not be fully 
> > accessible
> > [0.878010] ata1.00: supports DRM functions and may not be fully 
> > accessible
> > [1.969486] [drm] Initialized drm 1.1.0 20060810
> > [1.990584] VGA switcheroo: detected Optimus DSM method 
> > \_SB_.PCI0.PEG_.VID_ handle
> > [1.990610] nouveau :01:00.0: enabling device (0004 -> 0007)
> > [1.990874] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
> > [1.990877] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
> > [1.990878] nouveau  [  DEVICE][:01:00.0] Family : NVC0
> > [1.992485] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for 
> > image...
> > [2.002182] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [2.002184] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> > [2.002243] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [2.002245] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> > [2.189928] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
> > [2.189935] nouveau  [   VBIOS][:01:00.0] using image from ACPI
> > [2.190143] nouveau  [   VBIOS][:01:00.0] BIT signature found
> > [2.190149] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
> > [2.190467] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
> > [2.190470] nouveau  [   VBIOS][:01:00.0] running init tables
> > [2.278184] nouveau  [ PFB][:01:00.0] RAM type: DDR3
> > [2.278189] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
> > [2.278192] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
> > [2.311802] nouveau  [ DRM] VRAM: 512 MiB
> > [2.311805] nouveau  [ DRM] GART: 512 MiB
> > [2.311810] nouveau  [ DRM] BIT BIOS found
> > [2.311814] nouveau  [ DRM] Bios version 70.08.b7.02
> > [2.311831] nouv

Re: nouveau GF108 kernel errors and graphics corruption when enabling another output

[Pasi Kärkkäinen]

On Thu, May 09, 2013 at 06:10:04PM +0300, Pasi Kärkkäinen wrote:
> Hello,
> 
> Any comments? Should I provide more logs, or try something I didn't try yet? 
>

I just tried Linux kernel 3.9.2, and it has the same kind of graphics corruption
when enabling second output on nouveau adapter.

dmesg errors from 3.9.2:

[   91.533612] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
[   91.533618] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
[   91.533856] nouveau E[PBUS][:01:00.0] MMIO read of 0x FAULT 
at 0x141820 [ IBUS ]
[  246.466283] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  246.466287] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  246.499229] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  246.499232] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  246.522166] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  246.522169] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28


-- Pasi
 
> 
> On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi Kärkkäinen wrote:
> > Hello,
> > 
> > Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is 
> > disabled in BIOS,
> > and only the Nvidia discreet GPU is enabled:
> > 
> > $ lspci | grep VGA
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> > 5400M] (rev a1)
> > 
> > 
> > I boot up the laptop with only using the laptop internal LVDS panel, and 
> > when in X session,
> > I connect DVI cable to the docking station. xrandr now correctly shows DP2 
> > as connected,
> > and when I enable the DVI display, I get these nouveau errors in the kernel 
> > dmesg:
> > 
> > [  103.196252] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
> > [  103.196257] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
> > [  103.353160] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.353163] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.353923] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.353925] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.354257] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.354259] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.354703] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.354705] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.404091] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.404094] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.418076] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.418078] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.418567] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.418569] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.418788] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.418789] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.419164] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.419166] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.419473] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.419474] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.420080] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.420082] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.420367] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.420369] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.423674] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.423676] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.471348] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0400, -28
> > [  103.471351] nouveau E[  VM][:01:00.0] failed to create 
> > 0x0200, -28
> > [  103.487327] nouveau E[  VM][:01:00.0] failed to create 
> &g

nouveau GF108 kernel crash in optimus mode when enabling external display output

[Pasi Kärkkäinen]

Hello,

ping also here.. any other information needed about this nouveau kernel crash? 

Thanks,

-- Pasi

On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi K?rkk?inen wrote:
> Hello,
> 
> Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS:
> 
> $ lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> 5400M] (rev a1)
> 
> $ uname -a
> Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> 
> I boot up the system with only laptop internal LVDS active on intel gpu, and 
> when in X session,
> I enable the second display on nouveau gpu connected to the dock DP2/DVI 
> connector.
> At this point the kernel crashes immediately. 
> 
> Screenshots of the kernel crash/stacktrace here:
> http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg
> http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg
> 
> hand-written bits from the kernel crash:
> 
> Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 
> 2349H2G/2349H2G
> RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 
> [nouveau]
> RSP: 0018:8803298357c8 EFLAGS: 00010206
> ..
> Process Xorg (pid: 1208,..)
> ..
> Call Trace:
> .. nouveau_vm_map_sg+0xc2/0x130 [nouveau]
> .. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau]
> .. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau]
> .. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau]
> .. nouveau_bo_move+0xa5/0x400 [nouveau]
> .. ttm_bo_handle_move_mem+0x245/0x610 [ttm]
> 
> More info from the screenshots above.. 
> 
> 
> dmesg drm bits before the crash:
> 
> [0.137586] vgaarb: device added: 
> PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
> [0.137590] vgaarb: device added: 
> PCI::01:00.0,decodes=io+mem,owns=none,locks=none
> [0.137591] vgaarb: loaded
> [0.137591] vgaarb: bridge control possible :01:00.0
> [0.137592] vgaarb: no bridge control possible :00:02.0
> [0.529802] fb0: VESA VGA frame buffer device
> [0.877212] ata1.00: supports DRM functions and may not be fully accessible
> [0.878010] ata1.00: supports DRM functions and may not be fully accessible
> [1.969486] [drm] Initialized drm 1.1.0 20060810
> [1.990584] VGA switcheroo: detected Optimus DSM method 
> \_SB_.PCI0.PEG_.VID_ handle
> [1.990610] nouveau :01:00.0: enabling device (0004 -> 0007)
> [1.990874] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
> [1.990877] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
> [1.990878] nouveau  [  DEVICE][:01:00.0] Family : NVC0
> [1.992485] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
> [2.002182] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [2.002184] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> [2.002243] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [2.002245] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> [2.189928] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
> [2.189935] nouveau  [   VBIOS][:01:00.0] using image from ACPI
> [2.190143] nouveau  [   VBIOS][:01:00.0] BIT signature found
> [2.190149] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
> [2.190467] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
> [2.190470] nouveau  [   VBIOS][:01:00.0] running init tables
> [2.278184] nouveau  [ PFB][:01:00.0] RAM type: DDR3
> [2.278189] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
> [2.278192] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
> [2.311802] nouveau  [ DRM] VRAM: 512 MiB
> [2.311805] nouveau  [ DRM] GART: 512 MiB
> [2.311810] nouveau  [ DRM] BIT BIOS found
> [2.311814] nouveau  [ DRM] Bios version 70.08.b7.02
> [2.311831] nouveau  [ DRM] TMDS table version 2.0
> [2.311832] nouveau  [ DRM] DCB version 4.0
> [2.311833] nouveau  [ DRM] DCB outp 00: 01800323 00010034
> [2.311834] nouveau  [ DRM] DCB outp 01: 02811300 
> [2.311835] nouveau  [ DRM] DCB outp 02: 028223a6 0f220010
> [2.311836] nouveau  [ DRM] DCB outp 03: 02822362 00020010
> [2.311837] nouveau  [ DRM] DCB outp 04: 048333b6 0f220010
> [2.311838] nouveau  [ DRM] DCB outp 05: 04833372 00020010
> [2.311839] nouveau  [ DRM] DCB outp 06: 088443c6 0f220010
> [2.311840] nouveau  [ DRM] DCB outp 07: 08844382 00020010
> [2.311841] nouveau  [ DRM] DCB conn 00: 0040
> [2.311842] nouveau  [ DRM] DCB conn 01: 0100
> [2.311843] nouveau  [ DRM] DCB conn 02: 00110246
> [2.311844] nouveau  [ DRM] DCB conn 03: 00220346
> [2.311845] nouveau  [ DRM] DCB conn 04: 01400446
> [2.312502] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [   

nouveau GF108 kernel errors and graphics corruption when enabling another output

[Pasi Kärkkäinen]

Hello,

Any comments? Should I provide more logs, or try something I didn't try yet? 

Thanks,

-- Pasi

On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi K?rkk?inen wrote:
> Hello,
> 
> Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled 
> in BIOS,
> and only the Nvidia discreet GPU is enabled:
> 
> $ lspci | grep VGA
> 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> 5400M] (rev a1)
> 
> 
> I boot up the laptop with only using the laptop internal LVDS panel, and when 
> in X session,
> I connect DVI cable to the docking station. xrandr now correctly shows DP2 as 
> connected,
> and when I enable the DVI display, I get these nouveau errors in the kernel 
> dmesg:
> 
> [  103.196252] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
> [  103.196257] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
> [  103.353160] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.353163] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.353923] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.353925] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.354257] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.354259] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.354703] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.354705] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.404091] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.404094] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.418076] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.418078] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.418567] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.418569] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.418788] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.418789] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.419164] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.419166] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.419473] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.419474] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.420080] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.420082] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.420367] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.420369] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.423674] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.423676] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.471348] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.471351] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.487327] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.487330] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.487675] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.487677] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.488222] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.488224] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.488834] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.488836] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.490843] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.490845] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> 
> 
> Should I file a freedesktop bug about this? 
> 
> DVI monitor output actually gets enabled, and I can see the desktop there, 
> but both the LVDS display and the DVI display are all messed up.
> 
> For example moving a window around leaves traces of other window contents,
> and the background image gets replaced with all kinds of corrupted patterns, 
> so graphics looks quite weird and corrupted on both displays.
> 
> Switching back to only using the internal LVDS (disabling DVI/DP2 output)
> fixes the graphics corruptions.
> 
> 
> $ uname -a
> Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> $ dmesg|grep -i nouveau
> 
> [1.935779] fb: conflicting fb hw usage nouveaufb vs VESA VGA - removing 
> generic driver
> [1.93

Re: nouveau GF108 kernel crash in optimus mode when enabling external display output

[Pasi Kärkkäinen]

Hello,

ping also here.. any other information needed about this nouveau kernel crash? 

Thanks,

-- Pasi

On Mon, May 06, 2013 at 12:06:04AM +0300, Pasi Kärkkäinen wrote:
> Hello,
> 
> Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS:
> 
> $ lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> 5400M] (rev a1)
> 
> $ uname -a
> Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> 
> I boot up the system with only laptop internal LVDS active on intel gpu, and 
> when in X session,
> I enable the second display on nouveau gpu connected to the dock DP2/DVI 
> connector.
> At this point the kernel crashes immediately. 
> 
> Screenshots of the kernel crash/stacktrace here:
> http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg
> http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg
> 
> hand-written bits from the kernel crash:
> 
> Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 
> 2349H2G/2349H2G
> RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 
> [nouveau]
> RSP: 0018:8803298357c8 EFLAGS: 00010206
> ..
> Process Xorg (pid: 1208,..)
> ..
> Call Trace:
> .. nouveau_vm_map_sg+0xc2/0x130 [nouveau]
> .. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau]
> .. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau]
> .. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau]
> .. nouveau_bo_move+0xa5/0x400 [nouveau]
> .. ttm_bo_handle_move_mem+0x245/0x610 [ttm]
> 
> More info from the screenshots above.. 
> 
> 
> dmesg drm bits before the crash:
> 
> [0.137586] vgaarb: device added: 
> PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
> [0.137590] vgaarb: device added: 
> PCI::01:00.0,decodes=io+mem,owns=none,locks=none
> [0.137591] vgaarb: loaded
> [0.137591] vgaarb: bridge control possible :01:00.0
> [0.137592] vgaarb: no bridge control possible :00:02.0
> [0.529802] fb0: VESA VGA frame buffer device
> [0.877212] ata1.00: supports DRM functions and may not be fully accessible
> [0.878010] ata1.00: supports DRM functions and may not be fully accessible
> [1.969486] [drm] Initialized drm 1.1.0 20060810
> [1.990584] VGA switcheroo: detected Optimus DSM method 
> \_SB_.PCI0.PEG_.VID_ handle
> [1.990610] nouveau :01:00.0: enabling device (0004 -> 0007)
> [1.990874] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
> [1.990877] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
> [1.990878] nouveau  [  DEVICE][:01:00.0] Family : NVC0
> [1.992485] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
> [2.002182] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [2.002184] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> [2.002243] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [2.002245] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> [2.189928] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
> [2.189935] nouveau  [   VBIOS][:01:00.0] using image from ACPI
> [2.190143] nouveau  [   VBIOS][:01:00.0] BIT signature found
> [2.190149] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
> [2.190467] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
> [2.190470] nouveau  [   VBIOS][:01:00.0] running init tables
> [2.278184] nouveau  [ PFB][:01:00.0] RAM type: DDR3
> [2.278189] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
> [2.278192] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
> [2.311802] nouveau  [ DRM] VRAM: 512 MiB
> [2.311805] nouveau  [ DRM] GART: 512 MiB
> [2.311810] nouveau  [ DRM] BIT BIOS found
> [2.311814] nouveau  [ DRM] Bios version 70.08.b7.02
> [2.311831] nouveau  [ DRM] TMDS table version 2.0
> [2.311832] nouveau  [ DRM] DCB version 4.0
> [2.311833] nouveau  [ DRM] DCB outp 00: 01800323 00010034
> [2.311834] nouveau  [ DRM] DCB outp 01: 02811300 
> [2.311835] nouveau  [ DRM] DCB outp 02: 028223a6 0f220010
> [2.311836] nouveau  [ DRM] DCB outp 03: 02822362 00020010
> [2.311837] nouveau  [ DRM] DCB outp 04: 048333b6 0f220010
> [2.311838] nouveau  [ DRM] DCB outp 05: 04833372 00020010
> [2.311839] nouveau  [ DRM] DCB outp 06: 088443c6 0f220010
> [2.311840] nouveau  [ DRM] DCB outp 07: 08844382 00020010
> [2.311841] nouveau  [ DRM] DCB conn 00: 0040
> [2.311842] nouveau 

Re: nouveau GF108 kernel errors and graphics corruption when enabling another output

[Pasi Kärkkäinen]

Hello,

Any comments? Should I provide more logs, or try something I didn't try yet? 

Thanks,

-- Pasi

On Sun, May 05, 2013 at 05:36:36PM +0300, Pasi Kärkkäinen wrote:
> Hello,
> 
> Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled 
> in BIOS,
> and only the Nvidia discreet GPU is enabled:
> 
> $ lspci | grep VGA
> 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 
> 5400M] (rev a1)
> 
> 
> I boot up the laptop with only using the laptop internal LVDS panel, and when 
> in X session,
> I connect DVI cable to the docking station. xrandr now correctly shows DP2 as 
> connected,
> and when I enable the DVI display, I get these nouveau errors in the kernel 
> dmesg:
> 
> [  103.196252] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
> [  103.196257] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
> [  103.353160] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.353163] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.353923] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.353925] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.354257] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.354259] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.354703] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.354705] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.404091] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.404094] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.418076] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.418078] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.418567] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.418569] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.418788] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.418789] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.419164] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.419166] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.419473] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.419474] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.420080] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.420082] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.420367] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.420369] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.423674] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.423676] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.471348] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.471351] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.487327] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.487330] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.487675] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.487677] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.488222] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.488224] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.488834] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.488836] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> [  103.490843] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
> -28
> [  103.490845] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
> -28
> 
> 
> Should I file a freedesktop bug about this? 
> 
> DVI monitor output actually gets enabled, and I can see the desktop there, 
> but both the LVDS display and the DVI display are all messed up.
> 
> For example moving a window around leaves traces of other window contents,
> and the background image gets replaced with all kinds of corrupted patterns, 
> so graphics looks quite weird and corrupted on both displays.
> 
> Switching back to only using the internal LVDS (di

nouveau GF108 kernel crash in optimus mode when enabling external display output

[Pasi Kärkkäinen]

Hello,

Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 5400M] 
(rev a1)

$ uname -a
Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I boot up the system with only laptop internal LVDS active on intel gpu, and 
when in X session,
I enable the second display on nouveau gpu connected to the dock DP2/DVI 
connector.
At this point the kernel crashes immediately. 

Screenshots of the kernel crash/stacktrace here:
http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg
http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg

hand-written bits from the kernel crash:

Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 
2349H2G/2349H2G
RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 
[nouveau]
RSP: 0018:8803298357c8 EFLAGS: 00010206
..
Process Xorg (pid: 1208,..)
..
Call Trace:
.. nouveau_vm_map_sg+0xc2/0x130 [nouveau]
.. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau]
.. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau]
.. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau]
.. nouveau_bo_move+0xa5/0x400 [nouveau]
.. ttm_bo_handle_move_mem+0x245/0x610 [ttm]

More info from the screenshots above.. 


dmesg drm bits before the crash:

[0.137586] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.137590] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=none,locks=none
[0.137591] vgaarb: loaded
[0.137591] vgaarb: bridge control possible :01:00.0
[0.137592] vgaarb: no bridge control possible :00:02.0
[0.529802] fb0: VESA VGA frame buffer device
[0.877212] ata1.00: supports DRM functions and may not be fully accessible
[0.878010] ata1.00: supports DRM functions and may not be fully accessible
[1.969486] [drm] Initialized drm 1.1.0 20060810
[1.990584] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG_.VID_ 
handle
[1.990610] nouveau :01:00.0: enabling device (0004 -> 0007)
[1.990874] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
[1.990877] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
[1.990878] nouveau  [  DEVICE][:01:00.0] Family : NVC0
[1.992485] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[2.002182] nouveau  [   VBIOS][:01:00.0] ... signature not found
[2.002184] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[2.002243] nouveau  [   VBIOS][:01:00.0] ... signature not found
[2.002245] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[2.189928] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[2.189935] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[2.190143] nouveau  [   VBIOS][:01:00.0] BIT signature found
[2.190149] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
[2.190467] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
[2.190470] nouveau  [   VBIOS][:01:00.0] running init tables
[2.278184] nouveau  [ PFB][:01:00.0] RAM type: DDR3
[2.278189] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
[2.278192] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
[2.311802] nouveau  [ DRM] VRAM: 512 MiB
[2.311805] nouveau  [ DRM] GART: 512 MiB
[2.311810] nouveau  [ DRM] BIT BIOS found
[2.311814] nouveau  [ DRM] Bios version 70.08.b7.02
[2.311831] nouveau  [ DRM] TMDS table version 2.0
[2.311832] nouveau  [ DRM] DCB version 4.0
[2.311833] nouveau  [ DRM] DCB outp 00: 01800323 00010034
[2.311834] nouveau  [ DRM] DCB outp 01: 02811300 
[2.311835] nouveau  [ DRM] DCB outp 02: 028223a6 0f220010
[2.311836] nouveau  [ DRM] DCB outp 03: 02822362 00020010
[2.311837] nouveau  [ DRM] DCB outp 04: 048333b6 0f220010
[2.311838] nouveau  [ DRM] DCB outp 05: 04833372 00020010
[2.311839] nouveau  [ DRM] DCB outp 06: 088443c6 0f220010
[2.311840] nouveau  [ DRM] DCB outp 07: 08844382 00020010
[2.311841] nouveau  [ DRM] DCB conn 00: 0040
[2.311842] nouveau  [ DRM] DCB conn 01: 0100
[2.311843] nouveau  [ DRM] DCB conn 02: 00110246
[2.311844] nouveau  [ DRM] DCB conn 03: 00220346
[2.311845] nouveau  [ DRM] DCB conn 04: 01400446
[2.312502] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[2.312503] [drm] No driver support for vblank timestamp query.
[2.312575] nouveau  [ DRM] ACPI backlight interface available, not 
registering our own
[2.312612] nouveau W[ DRM] voltage table 0x50 unknown
[2.312769] nouveau  [ DRM] 2 available performance level(s)
[2.312771] nouveau  [ DRM] 1: core 270MHz shader 540MHz memory 405MHz
[  

nouveau GF108 kernel errors and graphics corruption when enabling another output

[Pasi Kärkkäinen]

Hello,

Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled 
in BIOS,
and only the Nvidia discreet GPU is enabled:

$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 5400M] 
(rev a1)


I boot up the laptop with only using the laptop internal LVDS panel, and when 
in X session,
I connect DVI cable to the docking station. xrandr now correctly shows DP2 as 
connected,
and when I enable the DVI display, I get these nouveau errors in the kernel 
dmesg:

[  103.196252] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
[  103.196257] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
[  103.353160] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.353163] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.353923] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.353925] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.354257] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.354259] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.354703] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.354705] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.404091] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.404094] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.418076] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.418078] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.418567] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.418569] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.418788] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.418789] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.419164] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.419166] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.419473] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.419474] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.420080] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.420082] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.420367] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.420369] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.423674] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.423676] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.471348] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.471351] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.487327] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.487330] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.487675] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.487677] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.488222] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.488224] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.488834] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.488836] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.490843] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.490845] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28


Should I file a freedesktop bug about this? 

DVI monitor output actually gets enabled, and I can see the desktop there, 
but both the LVDS display and the DVI display are all messed up.

For example moving a window around leaves traces of other window contents,
and the background image gets replaced with all kinds of corrupted patterns, 
so graphics looks quite weird and corrupted on both displays.

Switching back to only using the internal LVDS (disabling DVI/DP2 output)
fixes the graphics corruptions.


$ uname -a
Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


$ dmesg|grep -i nouveau

[1.935779] fb: conflicting fb hw usage nouveaufb vs VESA VGA - removing 
generic driver
[1.936042] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
[1.936044] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
[1.936045] nouveau  [  DEVICE][:01:00.0] Family : NVC0
[1.937112] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[1.991441] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[1.991443] nouveau  [   VBIOS][:01:00.0] using image from P

nouveau GF108 kernel crash in optimus mode when enabling external display output

[Pasi Kärkkäinen]

Hello,

Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 5400M] 
(rev a1)

$ uname -a
Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I boot up the system with only laptop internal LVDS active on intel gpu, and 
when in X session,
I enable the second display on nouveau gpu connected to the dock DP2/DVI 
connector.
At this point the kernel crashes immediately. 

Screenshots of the kernel crash/stacktrace here:
http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg
http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg

hand-written bits from the kernel crash:

Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 
2349H2G/2349H2G
RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 
[nouveau]
RSP: 0018:8803298357c8 EFLAGS: 00010206
..
Process Xorg (pid: 1208,..)
..
Call Trace:
.. nouveau_vm_map_sg+0xc2/0x130 [nouveau]
.. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau]
.. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau]
.. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau]
.. nouveau_bo_move+0xa5/0x400 [nouveau]
.. ttm_bo_handle_move_mem+0x245/0x610 [ttm]

More info from the screenshots above.. 


dmesg drm bits before the crash:

[0.137586] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.137590] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=none,locks=none
[0.137591] vgaarb: loaded
[0.137591] vgaarb: bridge control possible :01:00.0
[0.137592] vgaarb: no bridge control possible :00:02.0
[0.529802] fb0: VESA VGA frame buffer device
[0.877212] ata1.00: supports DRM functions and may not be fully accessible
[0.878010] ata1.00: supports DRM functions and may not be fully accessible
[1.969486] [drm] Initialized drm 1.1.0 20060810
[1.990584] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG_.VID_ 
handle
[1.990610] nouveau :01:00.0: enabling device (0004 -> 0007)
[1.990874] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
[1.990877] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
[1.990878] nouveau  [  DEVICE][:01:00.0] Family : NVC0
[1.992485] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[2.002182] nouveau  [   VBIOS][:01:00.0] ... signature not found
[2.002184] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[2.002243] nouveau  [   VBIOS][:01:00.0] ... signature not found
[2.002245] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[2.189928] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[2.189935] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[2.190143] nouveau  [   VBIOS][:01:00.0] BIT signature found
[2.190149] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
[2.190467] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
[2.190470] nouveau  [   VBIOS][:01:00.0] running init tables
[2.278184] nouveau  [ PFB][:01:00.0] RAM type: DDR3
[2.278189] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
[2.278192] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
[2.311802] nouveau  [ DRM] VRAM: 512 MiB
[2.311805] nouveau  [ DRM] GART: 512 MiB
[2.311810] nouveau  [ DRM] BIT BIOS found
[2.311814] nouveau  [ DRM] Bios version 70.08.b7.02
[2.311831] nouveau  [ DRM] TMDS table version 2.0
[2.311832] nouveau  [ DRM] DCB version 4.0
[2.311833] nouveau  [ DRM] DCB outp 00: 01800323 00010034
[2.311834] nouveau  [ DRM] DCB outp 01: 02811300 
[2.311835] nouveau  [ DRM] DCB outp 02: 028223a6 0f220010
[2.311836] nouveau  [ DRM] DCB outp 03: 02822362 00020010
[2.311837] nouveau  [ DRM] DCB outp 04: 048333b6 0f220010
[2.311838] nouveau  [ DRM] DCB outp 05: 04833372 00020010
[2.311839] nouveau  [ DRM] DCB outp 06: 088443c6 0f220010
[2.311840] nouveau  [ DRM] DCB outp 07: 08844382 00020010
[2.311841] nouveau  [ DRM] DCB conn 00: 0040
[2.311842] nouveau  [ DRM] DCB conn 01: 0100
[2.311843] nouveau  [ DRM] DCB conn 02: 00110246
[2.311844] nouveau  [ DRM] DCB conn 03: 00220346
[2.311845] nouveau  [ DRM] DCB conn 04: 01400446
[2.312502] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[2.312503] [drm] No driver support for vblank timestamp query.
[2.312575] nouveau  [ DRM] ACPI backlight interface available, not 
registering our own
[2.312612] nouveau W[ DRM] voltage table 0x50 unknown
[2.312769] nouveau  [ DRM] 2 available performance level(s)
[2.312771] nouveau  [ DRM] 1: core 270MHz shader 540MHz memory 405MHz
[  

nouveau GF108 kernel errors and graphics corruption when enabling another output

[Pasi Kärkkäinen]

Hello,

Lenovo T430 laptop with intel/nvidia hybrid graphics, but optimus is disabled 
in BIOS,
and only the Nvidia discreet GPU is enabled:

$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 5400M] 
(rev a1)


I boot up the laptop with only using the laptop internal LVDS panel, and when 
in X session,
I connect DVI cable to the docking station. xrandr now correctly shows DP2 as 
connected,
and when I enable the DVI display, I get these nouveau errors in the kernel 
dmesg:

[  103.196252] nouveau  [   PLTCG][:01:00.0] LTC0_LTS0: 0x036f0040
[  103.196257] nouveau  [   PLTCG][:01:00.0] LTC0_LTS1: 0x036f0040
[  103.353160] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.353163] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.353923] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.353925] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.354257] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.354259] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.354703] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.354705] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.404091] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.404094] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.418076] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.418078] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.418567] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.418569] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.418788] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.418789] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.419164] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.419166] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.419473] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.419474] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.420080] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.420082] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.420367] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.420369] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.423674] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.423676] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.471348] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.471351] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.487327] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.487330] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.487675] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.487677] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.488222] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.488224] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.488834] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.488836] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28
[  103.490843] nouveau E[  VM][:01:00.0] failed to create 0x0400, 
-28
[  103.490845] nouveau E[  VM][:01:00.0] failed to create 0x0200, 
-28


Should I file a freedesktop bug about this? 

DVI monitor output actually gets enabled, and I can see the desktop there, 
but both the LVDS display and the DVI display are all messed up.

For example moving a window around leaves traces of other window contents,
and the background image gets replaced with all kinds of corrupted patterns, 
so graphics looks quite weird and corrupted on both displays.

Switching back to only using the internal LVDS (disabling DVI/DP2 output)
fixes the graphics corruptions.


$ uname -a
Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


$ dmesg|grep -i nouveau

[1.935779] fb: conflicting fb hw usage nouveaufb vs VESA VGA - removing 
generic driver
[1.936042] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
[1.936044] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
[1.936045] nouveau  [  DEVICE][:01:00.0] Family : NVC0
[1.937112] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[1.991441] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[1.991443] nouveau  [   VBIOS][:01:00.0] using image from P

[Bug 29842] Radeon runs very hot

[Pasi Kärkkäinen]

On Wed, Feb 22, 2012 at 04:56:26PM +, bugzilla-daemon at 
bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=29842
> 
> 
> 
> 
> 
> --- Comment #14 from Igor Rudchenko   2012-02-22 
> 16:56:23 ---
> Commit "PCI: Rework ASPM disable code" added in 3.0.20 and 3.2.25 has worsened
> the situation. I can't enable ASPM on ThinkPad T60 now even with
> "pcie_aspm=force" kernel parameter. So radeon is always hot now.
> 

Are you sure it's about ASPM ? My radeon (On a HP laptop) is very hot because
of the unimplemented (and/or buggy) power management in the radeon driver!

I can make the temperature lower if I switch to power_profile "low" instead of 
the "default".

-- Pasi

> 
> 3.2.4 kernel:
> 
> # dmesg | grep ASPM
> [0.00] PCIe ASPM is forcibly enabled
> [0.161612] ACPI FADT declares the system doesn't support PCIe ASPM, so
> disable it
> [3.612673] e1000e :02:00.0: Disabling ASPM L0s L1
> 
> # lspci -vv -s 01:00.0 | grep ASPM
> LnkCap:Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, 
> L1
> <1us
> LnkCtl:ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
> 
> # cat /proc/acpi/ibm/thermal
> temperatures:49 41 37 68 36 -128 33 -128 42 54 55 -128 -128 -128 -128 -128
> 
> 
> 3.2.5 kernel:
> 
> # dmesg | grep ASPM
> [0.00] PCIe ASPM is forcibly enabled
> [0.161614] ACPI FADT declares the system doesn't support PCIe ASPM, so
> disable it
> [3.523647] e1000e :02:00.0: Disabling ASPM L0s L1
> 
> # lspci -vv -s 01:00.0 | grep ASPM
> LnkCap:Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, 
> L1
> <1us
> LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> 
> # cat /proc/acpi/ibm/thermal
> temperatures:51 41 37 72 36 -128 33 -128 43 55 59 -128 -128 -128 -128 -128
> 
> 
> Already tested kernels 3.2.7 and 3.3-rc4 - same problem.
> 
> -- 
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are watching the assignee of the bug.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 29842] Radeon runs very hot

[Pasi Kärkkäinen]

On Wed, Feb 22, 2012 at 04:56:26PM +, bugzilla-dae...@bugzilla.kernel.org 
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=29842
> 
> 
> 
> 
> 
> --- Comment #14 from Igor Rudchenko   2012-02-22 16:56:23 
> ---
> Commit "PCI: Rework ASPM disable code" added in 3.0.20 and 3.2.25 has worsened
> the situation. I can't enable ASPM on ThinkPad T60 now even with
> "pcie_aspm=force" kernel parameter. So radeon is always hot now.
> 

Are you sure it's about ASPM ? My radeon (On a HP laptop) is very hot because
of the unimplemented (and/or buggy) power management in the radeon driver!

I can make the temperature lower if I switch to power_profile "low" instead of 
the "default".

-- Pasi

> 
> 3.2.4 kernel:
> 
> # dmesg | grep ASPM
> [0.00] PCIe ASPM is forcibly enabled
> [0.161612] ACPI FADT declares the system doesn't support PCIe ASPM, so
> disable it
> [3.612673] e1000e :02:00.0: Disabling ASPM L0s L1
> 
> # lspci -vv -s 01:00.0 | grep ASPM
> LnkCap:Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, 
> L1
> <1us
> LnkCtl:ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
> 
> # cat /proc/acpi/ibm/thermal
> temperatures:49 41 37 68 36 -128 33 -128 42 54 55 -128 -128 -128 -128 -128
> 
> 
> 3.2.5 kernel:
> 
> # dmesg | grep ASPM
> [0.00] PCIe ASPM is forcibly enabled
> [0.161614] ACPI FADT declares the system doesn't support PCIe ASPM, so
> disable it
> [3.523647] e1000e :02:00.0: Disabling ASPM L0s L1
> 
> # lspci -vv -s 01:00.0 | grep ASPM
> LnkCap:Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, 
> L1
> <1us
> LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> 
> # cat /proc/acpi/ibm/thermal
> temperatures:51 41 37 72 36 -128 33 -128 43 55 59 -128 -128 -128 -128 -128
> 
> 
> Already tested kernels 3.2.7 and 3.3-rc4 - same problem.
> 
> -- 
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are watching the assignee of the bug.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeon issues on MacBook Pro 8,2

[Pasi Kärkkäinen]

On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
> > On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee
> >  wrote:
> > > I'm seeing several issues related to the radeon driver on a MacBook Pro
> > > 8,2 with the following graphics card:
> > >
> > > ?ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
> > >
> > > All problems were observed when using kernel version 3.2.1. None are
> > > seen when using fglrx.
> > >
> > > ?1. Excessive power draw. When using the radeon driver ACPI reports a
> > > ? ?power draw of about 30W on an idle desktop. Using fglrx brings this
> > > ? ?number down to 15W.
> > 
> > The power saving features of the open source driver are not yet as
> > good as the closed source driver.  Please see the power management
> > section of this page (http://wiki.x.org/wiki/RadeonFeature) for more
> > info on the options currently available.
> 
> The dynpm option makes a small difference, saving about 2W. I did notice
> an ocassional flash on the screen with this option, and the same flash
> each time I changed the power options.
> 

Btw how do you measure the power draw? 


> The only thing that improves things significatnly is the "low" profile
> method, which gets it down to about 18.5W.
> 

I have older radeon (Mobility HD3650) and only the "low" profile makes it 
usable.. 
the "default" profile will overheat the laptop and crash it, or then Linux does 
automatic emergency thermal shutdown to protect the laptop.

If I boot some Linux livecd the laptop will basicly overheat and shutdown by 
itself
before the desktop is loaded from the livecd.. :( 

-- Pasi

Re: radeon issues on MacBook Pro 8,2

[Pasi Kärkkäinen]

On Thu, Jan 19, 2012 at 02:53:17PM -0600, Seth Forshee wrote:
> On Thu, Jan 19, 2012 at 02:48:52PM -0500, Alex Deucher wrote:
> > On Thu, Jan 19, 2012 at 12:18 PM, Seth Forshee
> >  wrote:
> > > I'm seeing several issues related to the radeon driver on a MacBook Pro
> > > 8,2 with the following graphics card:
> > >
> > >  ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] [1002:6741]
> > >
> > > All problems were observed when using kernel version 3.2.1. None are
> > > seen when using fglrx.
> > >
> > >  1. Excessive power draw. When using the radeon driver ACPI reports a
> > >    power draw of about 30W on an idle desktop. Using fglrx brings this
> > >    number down to 15W.
> > 
> > The power saving features of the open source driver are not yet as
> > good as the closed source driver.  Please see the power management
> > section of this page (http://wiki.x.org/wiki/RadeonFeature) for more
> > info on the options currently available.
> 
> The dynpm option makes a small difference, saving about 2W. I did notice
> an ocassional flash on the screen with this option, and the same flash
> each time I changed the power options.
> 

Btw how do you measure the power draw? 


> The only thing that improves things significatnly is the "low" profile
> method, which gets it down to about 18.5W.
> 

I have older radeon (Mobility HD3650) and only the "low" profile makes it 
usable.. 
the "default" profile will overheat the laptop and crash it, or then Linux does 
automatic emergency thermal shutdown to protect the laptop.

If I boot some Linux livecd the laptop will basicly overheat and shutdown by 
itself
before the desktop is loaded from the livecd.. :( 

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeon power_profile "default" causes laptop overheating and crashes

[Pasi Kärkkäinen]

On Mon, Aug 29, 2011 at 07:20:16PM +0300, Pasi K?rkk?inen wrote:
> Hello,
> 
> I have a laptop with Mobility Radeon HD 3650, and the opensource radeon 
> driver makes
> the laptop overheat and crash (or kernel does thermal emergency shutdowns).
> Even when the laptop is totally *idle* the system overheats!
> 
> As a default power_profile "default" is in use (and causes problems):
> # cat /sys/class/drm/card0/device/power_profile
> default
> 
> I can workaround the issue with:
> # echo low > /sys/class/drm/card0/device/power_profile
> 
> .. which makes the temperature go down 10-20 degrees celsius,
> and the fans slow down and the system feels much cooler.
> 
> I've seen this problem with Linux 2.6.35 (Fedora 14), Linux 2.6.38 (Fedora 15)
> and Linux 3.0.0 (Fedora 16 alpha).
> 
> Is there anything I should try to troubleshoot the problem? 
> Is "default" power_profile supposed to cause overheating?
> 
> Using proprietary AMD fglrx driver doesn't have this problem, 
> fglrx works out-of-the-box and the laptop does not overheat.
> 
> dmesg from Linux 3.0.0 here: 
> http://pasik.reaktio.net/fedora/f16/dmesg-hp-elitebook-8530p-f16-alpha.txt
> 

Ping?

-- Pasi

Re: radeon power_profile "default" causes laptop overheating and crashes

[Pasi Kärkkäinen]

On Mon, Aug 29, 2011 at 07:20:16PM +0300, Pasi Kärkkäinen wrote:
> Hello,
> 
> I have a laptop with Mobility Radeon HD 3650, and the opensource radeon 
> driver makes
> the laptop overheat and crash (or kernel does thermal emergency shutdowns).
> Even when the laptop is totally *idle* the system overheats!
> 
> As a default power_profile "default" is in use (and causes problems):
> # cat /sys/class/drm/card0/device/power_profile
> default
> 
> I can workaround the issue with:
> # echo low > /sys/class/drm/card0/device/power_profile
> 
> .. which makes the temperature go down 10-20 degrees celsius,
> and the fans slow down and the system feels much cooler.
> 
> I've seen this problem with Linux 2.6.35 (Fedora 14), Linux 2.6.38 (Fedora 15)
> and Linux 3.0.0 (Fedora 16 alpha).
> 
> Is there anything I should try to troubleshoot the problem? 
> Is "default" power_profile supposed to cause overheating?
> 
> Using proprietary AMD fglrx driver doesn't have this problem, 
> fglrx works out-of-the-box and the laptop does not overheat.
> 
> dmesg from Linux 3.0.0 here: 
> http://pasik.reaktio.net/fedora/f16/dmesg-hp-elitebook-8530p-f16-alpha.txt
> 

Ping?

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeon power_profile "default" causes laptop overheating and crashes

[Pasi Kärkkäinen]

Hello,

I have a laptop with Mobility Radeon HD 3650, and the opensource radeon driver 
makes
the laptop overheat and crash (or kernel does thermal emergency shutdowns).
Even when the laptop is totally *idle* the system overheats!

As a default power_profile "default" is in use (and causes problems):
# cat /sys/class/drm/card0/device/power_profile
default

I can workaround the issue with:
# echo low > /sys/class/drm/card0/device/power_profile

.. which makes the temperature go down 10-20 degrees celsius,
and the fans slow down and the system feels much cooler.

I've seen this problem with Linux 2.6.35 (Fedora 14), Linux 2.6.38 (Fedora 15)
and Linux 3.0.0 (Fedora 16 alpha).

Is there anything I should try to troubleshoot the problem? 
Is "default" power_profile supposed to cause overheating?

Using proprietary AMD fglrx driver doesn't have this problem, 
fglrx works out-of-the-box and the laptop does not overheat.

dmesg from Linux 3.0.0 here: 
http://pasik.reaktio.net/fedora/f16/dmesg-hp-elitebook-8530p-f16-alpha.txt

Thanks,

-- Pasi

radeon power_profile "default" causes laptop overheating and crashes

[Pasi Kärkkäinen]

Hello,

I have a laptop with Mobility Radeon HD 3650, and the opensource radeon driver 
makes
the laptop overheat and crash (or kernel does thermal emergency shutdowns).
Even when the laptop is totally *idle* the system overheats!

As a default power_profile "default" is in use (and causes problems):
# cat /sys/class/drm/card0/device/power_profile
default

I can workaround the issue with:
# echo low > /sys/class/drm/card0/device/power_profile

.. which makes the temperature go down 10-20 degrees celsius,
and the fans slow down and the system feels much cooler.

I've seen this problem with Linux 2.6.35 (Fedora 14), Linux 2.6.38 (Fedora 15)
and Linux 3.0.0 (Fedora 16 alpha).

Is there anything I should try to troubleshoot the problem? 
Is "default" power_profile supposed to cause overheating?

Using proprietary AMD fglrx driver doesn't have this problem, 
fglrx works out-of-the-box and the laptop does not overheat.

dmesg from Linux 3.0.0 here: 
http://pasik.reaktio.net/fedora/f16/dmesg-hp-elitebook-8530p-f16-alpha.txt

Thanks,

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Status of Radeon power management / laptop overheating

[Pasi Kärkkäinen]

On Mon, Jul 11, 2011 at 11:26:32PM +0300, Pasi K?rkk?inen wrote:
> Hello,
> 
> Does someone know the current status of radeon power management in Linux?
> and also the roadmap/todo?
> 
> I have a laptop than runs *very* hot in Linux, while it's cool in Windows,
> and the difference seems to be mostly about radeon graphics driver.
> 
> The default power_profile makes the laptop run *very* hot, 
> and Linux does "thermal emergency shutdowns" pretty often.
> 
> When I change the default radeon power_profile to "mid" or "low" the 
> temperature
> goes down by 10-20 degrees celsius, but it's still more hot in Linux compared 
> to Windows.
> 
> Some bugzillas from Fedora:
> 
>   "Computer becomes very hot (2011 27inch iMac)":
>   https://bugzilla.redhat.com/show_bug.cgi?id=702953
> 
>   "radeon driver default power profile causes laptop overheating":
>   https://bugzilla.redhat.com/show_bug.cgi?id=714474
> 
> 
> My testing is done with Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38).
> 
> Thanks,
> 

Any thoughts about this? 

-- Pasi

Re: Status of Radeon power management / laptop overheating

[Pasi Kärkkäinen]

On Mon, Jul 11, 2011 at 11:26:32PM +0300, Pasi Kärkkäinen wrote:
> Hello,
> 
> Does someone know the current status of radeon power management in Linux?
> and also the roadmap/todo?
> 
> I have a laptop than runs *very* hot in Linux, while it's cool in Windows,
> and the difference seems to be mostly about radeon graphics driver.
> 
> The default power_profile makes the laptop run *very* hot, 
> and Linux does "thermal emergency shutdowns" pretty often.
> 
> When I change the default radeon power_profile to "mid" or "low" the 
> temperature
> goes down by 10-20 degrees celsius, but it's still more hot in Linux compared 
> to Windows.
> 
> Some bugzillas from Fedora:
> 
>   "Computer becomes very hot (2011 27inch iMac)":
>   https://bugzilla.redhat.com/show_bug.cgi?id=702953
> 
>   "radeon driver default power profile causes laptop overheating":
>   https://bugzilla.redhat.com/show_bug.cgi?id=714474
> 
> 
> My testing is done with Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38).
> 
> Thanks,
> 

Any thoughts about this? 

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Status of Radeon power management / laptop overheating

[Pasi Kärkkäinen]

Hello,

Does someone know the current status of radeon power management in Linux?
and also the roadmap/todo?

I have a laptop than runs *very* hot in Linux, while it's cool in Windows,
and the difference seems to be mostly about radeon graphics driver.

The default power_profile makes the laptop run *very* hot, 
and Linux does "thermal emergency shutdowns" pretty often.

When I change the default radeon power_profile to "mid" or "low" the temperature
goes down by 10-20 degrees celsius, but it's still more hot in Linux compared 
to Windows.

Some bugzillas from Fedora:

"Computer becomes very hot (2011 27inch iMac)":
https://bugzilla.redhat.com/show_bug.cgi?id=702953

"radeon driver default power profile causes laptop overheating":
https://bugzilla.redhat.com/show_bug.cgi?id=714474


My testing is done with Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38).

Thanks,

-- Pasi

Status of Radeon power management / laptop overheating

[Pasi Kärkkäinen]

Hello,

Does someone know the current status of radeon power management in Linux?
and also the roadmap/todo?

I have a laptop than runs *very* hot in Linux, while it's cool in Windows,
and the difference seems to be mostly about radeon graphics driver.

The default power_profile makes the laptop run *very* hot, 
and Linux does "thermal emergency shutdowns" pretty often.

When I change the default radeon power_profile to "mid" or "low" the temperature
goes down by 10-20 degrees celsius, but it's still more hot in Linux compared 
to Windows.

Some bugzillas from Fedora:

"Computer becomes very hot (2011 27inch iMac)":
https://bugzilla.redhat.com/show_bug.cgi?id=702953

"radeon driver default power profile causes laptop overheating":
https://bugzilla.redhat.com/show_bug.cgi?id=714474


My testing is done with Fedora 14 (Linux 2.6.35) and Fedora 15 (Linux 2.6.38).

Thanks,

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

ApiTrace: OpenGL tracer, analyzer, debugger, replayer..

[Pasi Kärkkäinen]

Hello,

This might be an interesting tool for dri/driver developers..

from opengl.org:
"New OpenGL tracer, analyzer and debugger:
ApiTrace is a brand new project to trace, replay, analyze and debug graphics 
APIs. Using it you can inspect the OpenGL state frame by frame, call by call. 
You can analyze every shader, every texture, every buffer. You can also edit 
the trace itself and see the effects it would have on rendering in real-time."

http://zrusin.blogspot.com/2011/04/apitrace.html

"As a driver developer you no longer have to install all the games just to 
debug a problem, the report can simply include a short trace which you can use 
to immediately figure out what's wrong. As an application developer you can 
inspect every graphics call your app makes, you can analyze your api usage and 
you could automatically produce standalone testcases which you can send to 
driver developers."

See the blog post for more info.

-- Pasi

ApiTrace: OpenGL tracer, analyzer, debugger, replayer..

[Pasi Kärkkäinen]

Hello,

This might be an interesting tool for dri/driver developers..

from opengl.org:
"New OpenGL tracer, analyzer and debugger:
ApiTrace is a brand new project to trace, replay, analyze and debug graphics 
APIs. Using it you can inspect the OpenGL state frame by frame, call by call. 
You can analyze every shader, every texture, every buffer. You can also edit 
the trace itself and see the effects it would have on rendering in real-time."

http://zrusin.blogspot.com/2011/04/apitrace.html

"As a driver developer you no longer have to install all the games just to 
debug a problem, the report can simply include a short trace which you can use 
to immediately figure out what's wrong. As an application developer you can 
inspect every graphics call your app makes, you can analyze your api usage and 
you could automatically produce standalone testcases which you can send to 
driver developers."

See the blog post for more info.

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Detecting if display is powered on or not

[Pasi Kärkkäinen]

On Sun, Oct 17, 2010 at 03:25:09PM -0400, Alex Deucher wrote:
> On Sun, Oct 17, 2010 at 9:07 AM, Pasi K?rkk?inen  wrote:
> > Hello,
> >
> > While I was discussing the laptop lid/dock issues with Fedora
> > people this issue was brought up.
> >
> > How do you determine if a display is actually powered on or not?
> >
> > Scenario:
> > - Laptop in a docking station, lid open, so internal LVDS enabled.
> > - External DVI display connected, but powered off.
> >
> > So in this case the external display shouldn't be used, since it's off.
> >
> > What happens is this:
> >
> > # cat /sys/class/drm/card0-DVI-D-1/status
> > connected
> >
> > # cat /sys/class/drm/card0-DVI-D-1/enabled
> > enabled
> >
> > # cat /sys/class/drm/card0-DVI-D-1/modes
> > 1920x1080
> > 1600x1200
> > 1680x1050
> > 1280x1024
> > 1440x900
> > 1280x960
> > 1280x800
> > 1024x768
> > 800x600
> > 800x600
> > 640x480
> >
> > So it *looks* like it's enabled and active, but actually it's powered off.
> > Is there a method to determine the actual state?
> >
> 
> Unfortunately not.  Monitors are designed to keep the EDID powered up
> even if the monitor is powered off so that graphics chips can detect
> that something is attached.  There's no way to know whether the
> monitor is on of off however.
> 

Ok. Understood.

And there are no other protocols that would reply only when the monitor is 
actually on? :)

-- Pasi

> Alex
> 
> > That is pretty important information for the daemon/tool/script implementing
> > the "policy" of which outputs to enable/disable..
> >
> > Thanks!
> >
> > -- Pasi
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Detecting if display is powered on or not

[Pasi Kärkkäinen]

On Sun, Oct 17, 2010 at 03:25:09PM -0400, Alex Deucher wrote:
> On Sun, Oct 17, 2010 at 9:07 AM, Pasi Kärkkäinen  wrote:
> > Hello,
> >
> > While I was discussing the laptop lid/dock issues with Fedora
> > people this issue was brought up.
> >
> > How do you determine if a display is actually powered on or not?
> >
> > Scenario:
> > - Laptop in a docking station, lid open, so internal LVDS enabled.
> > - External DVI display connected, but powered off.
> >
> > So in this case the external display shouldn't be used, since it's off.
> >
> > What happens is this:
> >
> > # cat /sys/class/drm/card0-DVI-D-1/status
> > connected
> >
> > # cat /sys/class/drm/card0-DVI-D-1/enabled
> > enabled
> >
> > # cat /sys/class/drm/card0-DVI-D-1/modes
> > 1920x1080
> > 1600x1200
> > 1680x1050
> > 1280x1024
> > 1440x900
> > 1280x960
> > 1280x800
> > 1024x768
> > 800x600
> > 800x600
> > 640x480
> >
> > So it *looks* like it's enabled and active, but actually it's powered off.
> > Is there a method to determine the actual state?
> >
> 
> Unfortunately not.  Monitors are designed to keep the EDID powered up
> even if the monitor is powered off so that graphics chips can detect
> that something is attached.  There's no way to know whether the
> monitor is on of off however.
> 

Ok. Understood.

And there are no other protocols that would reply only when the monitor is 
actually on? :)

-- Pasi

> Alex
> 
> > That is pretty important information for the daemon/tool/script implementing
> > the "policy" of which outputs to enable/disable..
> >
> > Thanks!
> >
> > -- Pasi
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Detecting if display is powered on or not

[Pasi Kärkkäinen]

Hello,

While I was discussing the laptop lid/dock issues with Fedora
people this issue was brought up.

How do you determine if a display is actually powered on or not? 

Scenario:
- Laptop in a docking station, lid open, so internal LVDS enabled.
- External DVI display connected, but powered off.

So in this case the external display shouldn't be used, since it's off.

What happens is this:

# cat /sys/class/drm/card0-DVI-D-1/status 
connected

# cat /sys/class/drm/card0-DVI-D-1/enabled 
enabled

# cat /sys/class/drm/card0-DVI-D-1/modes
1920x1080
1600x1200
1680x1050
1280x1024
1440x900
1280x960
1280x800
1024x768
800x600
800x600
640x480

So it *looks* like it's enabled and active, but actually it's powered off.
Is there a method to determine the actual state? 

That is pretty important information for the daemon/tool/script implementing
the "policy" of which outputs to enable/disable..

Thanks!

-- Pasi

Detecting if display is powered on or not

[Pasi Kärkkäinen]

Hello,

While I was discussing the laptop lid/dock issues with Fedora
people this issue was brought up.

How do you determine if a display is actually powered on or not? 

Scenario:
- Laptop in a docking station, lid open, so internal LVDS enabled.
- External DVI display connected, but powered off.

So in this case the external display shouldn't be used, since it's off.

What happens is this:

# cat /sys/class/drm/card0-DVI-D-1/status 
connected

# cat /sys/class/drm/card0-DVI-D-1/enabled 
enabled

# cat /sys/class/drm/card0-DVI-D-1/modes
1920x1080
1600x1200
1680x1050
1280x1024
1440x900
1280x960
1280x800
1024x768
800x600
800x600
640x480

So it *looks* like it's enabled and active, but actually it's powered off.
Is there a method to determine the actual state? 

That is pretty important information for the daemon/tool/script implementing
the "policy" of which outputs to enable/disable..

Thanks!

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Tue, Sep 21, 2010 at 01:09:37AM -0400, Alex Deucher wrote:
> On Mon, Sep 20, 2010 at 1:53 AM, Pasi K?rkk?inen  wrote:
> > On Sun, Sep 19, 2010 at 11:56:27PM -0400, Alex Deucher wrote:
> >> On Sun, Sep 19, 2010 at 10:56 AM, Pasi K?rkk?inen  wrote:
> >> > On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi K?rkk?inen wrote:
> >> >> > >
> >> >> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my 
> >> >> > > laptop,
> >> >> > > but is there a way to monitor the state of the drm/kms outputs from 
> >> >> > > /proc, /sys or from somewhere?
> >> >> > >
> >> >> > > I'd like to see the state before X is started, and verify what 
> >> >> > > happens when GDM is started etc..
> >> >> > > (ie. if outputs are enabled/active or not).
> >> >> > >
> >> >> >
> >> >> > Ah, found it:
> >> >> >
> >> >> > $ ls /sys/class/drm/card0
> >> >> > card0-DVI-D-1 ? ? ? ?card0-LVDS-1 ?dev ? ? power ? ? ?uevent
> >> >> > card0-HDMI Type A-1 ?card0-VGA-1 ? device ?subsystem
> >> >> >
> >> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
> >> >> > connected
> >> >> >
> >> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
> >> >> > enabled
> >> >> >
> >> >>
> >> >> So I added those to rc.local so that they get executed before GDM..
> >> >> and I booted up the laptop with the lid closed..
> >> >>
> >> >> And the result was: lid state "closed", lvds-status "connected" and 
> >> >> lvds-enabled was "enabled"..
> >> >>
> >> >> Does that mean Fedora plymouth is doing it wrong,
> >> >> or is t possible the driver itself always enabled the lvds, even when 
> >> >> the lid is closed?
> >> >>
> >> >
> >> > I did some more investigations. I'm currently using Fedora 13 Linux 
> >> > 2.6.34.6-47.fc13.x86_64 kernel.
> >> > I hacked the initrd image to echo debug stuff right after drm modules 
> >> > are loaded,
> >> > and *before* plymouth is started (and then sleep for some time so that I 
> >> > have time to see the debug values.)
> >> >
> >> > The result was this:
> >> >
> >> > acpi lid/state: closed
> >> > lvds-1/status: connected
> >> > lvds-1/enabled: enabled
> >> >
> >> > So to me it looks like the problem is in the driver itself..
> >> > lvds shouldn't get enabled (turned on) when the lid is closed..
> >>
> >> As I've stated previously, the driver always reports LVDS as connected
> >> because it is always connected. ?It's up to userspace to decide on
> >> what policy (enabled or disabled) to implement when the lid is open vs
> >> closed.
> >>
> >
> > Yep, I do realize it's always connected.
> >
> > But the question was supposed to be more about the enabled/disabled part..
> > It isn't possible to check the acpi lid status from the driver?
> 
> It is possible but:
> 
> 1. Acpi lid status is very unreliable on a lot of notebooks
>

Yeah.. seems to work fine on mine though.

> 2. Policy is set in userspace, so your desktop manager should decide
> what to enable in what cases.
> 

Police in userspace makes sense..

> Also there are laptops with built in color management tools that
> require the panel be on when the lid is closed to run.
> 

Hmm.. ok.
So I guess I'll have to continue with plymouth/gdm/Xorg people..

Thanks!

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Tue, Sep 21, 2010 at 01:09:37AM -0400, Alex Deucher wrote:
> On Mon, Sep 20, 2010 at 1:53 AM, Pasi Kärkkäinen  wrote:
> > On Sun, Sep 19, 2010 at 11:56:27PM -0400, Alex Deucher wrote:
> >> On Sun, Sep 19, 2010 at 10:56 AM, Pasi Kärkkäinen  wrote:
> >> > On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
> >> >> > >
> >> >> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my 
> >> >> > > laptop,
> >> >> > > but is there a way to monitor the state of the drm/kms outputs from 
> >> >> > > /proc, /sys or from somewhere?
> >> >> > >
> >> >> > > I'd like to see the state before X is started, and verify what 
> >> >> > > happens when GDM is started etc..
> >> >> > > (ie. if outputs are enabled/active or not).
> >> >> > >
> >> >> >
> >> >> > Ah, found it:
> >> >> >
> >> >> > $ ls /sys/class/drm/card0
> >> >> > card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
> >> >> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> >> >> >
> >> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
> >> >> > connected
> >> >> >
> >> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
> >> >> > enabled
> >> >> >
> >> >>
> >> >> So I added those to rc.local so that they get executed before GDM..
> >> >> and I booted up the laptop with the lid closed..
> >> >>
> >> >> And the result was: lid state "closed", lvds-status "connected" and 
> >> >> lvds-enabled was "enabled"..
> >> >>
> >> >> Does that mean Fedora plymouth is doing it wrong,
> >> >> or is t possible the driver itself always enabled the lvds, even when 
> >> >> the lid is closed?
> >> >>
> >> >
> >> > I did some more investigations. I'm currently using Fedora 13 Linux 
> >> > 2.6.34.6-47.fc13.x86_64 kernel.
> >> > I hacked the initrd image to echo debug stuff right after drm modules 
> >> > are loaded,
> >> > and *before* plymouth is started (and then sleep for some time so that I 
> >> > have time to see the debug values.)
> >> >
> >> > The result was this:
> >> >
> >> > acpi lid/state: closed
> >> > lvds-1/status: connected
> >> > lvds-1/enabled: enabled
> >> >
> >> > So to me it looks like the problem is in the driver itself..
> >> > lvds shouldn't get enabled (turned on) when the lid is closed..
> >>
> >> As I've stated previously, the driver always reports LVDS as connected
> >> because it is always connected.  It's up to userspace to decide on
> >> what policy (enabled or disabled) to implement when the lid is open vs
> >> closed.
> >>
> >
> > Yep, I do realize it's always connected.
> >
> > But the question was supposed to be more about the enabled/disabled part..
> > It isn't possible to check the acpi lid status from the driver?
> 
> It is possible but:
> 
> 1. Acpi lid status is very unreliable on a lot of notebooks
>

Yeah.. seems to work fine on mine though.

> 2. Policy is set in userspace, so your desktop manager should decide
> what to enable in what cases.
> 

Police in userspace makes sense..

> Also there are laptops with built in color management tools that
> require the panel be on when the lid is closed to run.
> 

Hmm.. ok.
So I guess I'll have to continue with plymouth/gdm/Xorg people..

Thanks!

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 11:56:27PM -0400, Alex Deucher wrote:
> On Sun, Sep 19, 2010 at 10:56 AM, Pasi K?rkk?inen  wrote:
> > On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi K?rkk?inen wrote:
> >> > >
> >> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my 
> >> > > laptop,
> >> > > but is there a way to monitor the state of the drm/kms outputs from 
> >> > > /proc, /sys or from somewhere?
> >> > >
> >> > > I'd like to see the state before X is started, and verify what happens 
> >> > > when GDM is started etc..
> >> > > (ie. if outputs are enabled/active or not).
> >> > >
> >> >
> >> > Ah, found it:
> >> >
> >> > $ ls /sys/class/drm/card0
> >> > card0-DVI-D-1 ? ? ? ?card0-LVDS-1 ?dev ? ? power ? ? ?uevent
> >> > card0-HDMI Type A-1 ?card0-VGA-1 ? device ?subsystem
> >> >
> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
> >> > connected
> >> >
> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
> >> > enabled
> >> >
> >>
> >> So I added those to rc.local so that they get executed before GDM..
> >> and I booted up the laptop with the lid closed..
> >>
> >> And the result was: lid state "closed", lvds-status "connected" and 
> >> lvds-enabled was "enabled"..
> >>
> >> Does that mean Fedora plymouth is doing it wrong,
> >> or is t possible the driver itself always enabled the lvds, even when the 
> >> lid is closed?
> >>
> >
> > I did some more investigations. I'm currently using Fedora 13 Linux 
> > 2.6.34.6-47.fc13.x86_64 kernel.
> > I hacked the initrd image to echo debug stuff right after drm modules are 
> > loaded,
> > and *before* plymouth is started (and then sleep for some time so that I 
> > have time to see the debug values.)
> >
> > The result was this:
> >
> > acpi lid/state: closed
> > lvds-1/status: connected
> > lvds-1/enabled: enabled
> >
> > So to me it looks like the problem is in the driver itself..
> > lvds shouldn't get enabled (turned on) when the lid is closed..
> 
> As I've stated previously, the driver always reports LVDS as connected
> because it is always connected.  It's up to userspace to decide on
> what policy (enabled or disabled) to implement when the lid is open vs
> closed.
> 

Yep, I do realize it's always connected.

But the question was supposed to be more about the enabled/disabled part.. 
It isn't possible to check the acpi lid status from the driver? 

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 11:56:27PM -0400, Alex Deucher wrote:
> On Sun, Sep 19, 2010 at 10:56 AM, Pasi Kärkkäinen  wrote:
> > On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
> >> > >
> >> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my 
> >> > > laptop,
> >> > > but is there a way to monitor the state of the drm/kms outputs from 
> >> > > /proc, /sys or from somewhere?
> >> > >
> >> > > I'd like to see the state before X is started, and verify what happens 
> >> > > when GDM is started etc..
> >> > > (ie. if outputs are enabled/active or not).
> >> > >
> >> >
> >> > Ah, found it:
> >> >
> >> > $ ls /sys/class/drm/card0
> >> > card0-DVI-D-1        card0-LVDS-1  dev     power      uevent
> >> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> >> >
> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/status
> >> > connected
> >> >
> >> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled
> >> > enabled
> >> >
> >>
> >> So I added those to rc.local so that they get executed before GDM..
> >> and I booted up the laptop with the lid closed..
> >>
> >> And the result was: lid state "closed", lvds-status "connected" and 
> >> lvds-enabled was "enabled"..
> >>
> >> Does that mean Fedora plymouth is doing it wrong,
> >> or is t possible the driver itself always enabled the lvds, even when the 
> >> lid is closed?
> >>
> >
> > I did some more investigations. I'm currently using Fedora 13 Linux 
> > 2.6.34.6-47.fc13.x86_64 kernel.
> > I hacked the initrd image to echo debug stuff right after drm modules are 
> > loaded,
> > and *before* plymouth is started (and then sleep for some time so that I 
> > have time to see the debug values.)
> >
> > The result was this:
> >
> > acpi lid/state: closed
> > lvds-1/status: connected
> > lvds-1/enabled: enabled
> >
> > So to me it looks like the problem is in the driver itself..
> > lvds shouldn't get enabled (turned on) when the lid is closed..
> 
> As I've stated previously, the driver always reports LVDS as connected
> because it is always connected.  It's up to userspace to decide on
> what policy (enabled or disabled) to implement when the lid is open vs
> closed.
> 

Yep, I do realize it's always connected.

But the question was supposed to be more about the enabled/disabled part.. 
It isn't possible to check the acpi lid status from the driver? 

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi K?rkk?inen wrote:
> > > 
> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> > > but is there a way to monitor the state of the drm/kms outputs from 
> > > /proc, /sys or from somewhere? 
> > > 
> > > I'd like to see the state before X is started, and verify what happens 
> > > when GDM is started etc.. 
> > > (ie. if outputs are enabled/active or not).
> > > 
> > 
> > Ah, found it:
> > 
> > $ ls /sys/class/drm/card0
> > card0-DVI-D-1card0-LVDS-1  dev power  uevent
> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> > 
> > $ cat /sys/class/drm/card0/card0-LVDS-1/status 
> > connected
> > 
> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
> > enabled
> > 
> 
> So I added those to rc.local so that they get executed before GDM..
> and I booted up the laptop with the lid closed..
> 
> And the result was: lid state "closed", lvds-status "connected" and 
> lvds-enabled was "enabled"..
> 
> Does that mean Fedora plymouth is doing it wrong,
> or is t possible the driver itself always enabled the lvds, even when the lid 
> is closed? 
> 

I did some more investigations. I'm currently using Fedora 13 Linux 
2.6.34.6-47.fc13.x86_64 kernel.
I hacked the initrd image to echo debug stuff right after drm modules are 
loaded, 
and *before* plymouth is started (and then sleep for some time so that I have 
time to see the debug values.)

The result was this:

acpi lid/state: closed
lvds-1/status: connected
lvds-1/enabled: enabled

So to me it looks like the problem is in the driver itself..
lvds shouldn't get enabled (turned on) when the lid is closed..

-- Pasi

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 02:34:03PM +0300, Pasi K?rkk?inen wrote:
> On Sun, Sep 19, 2010 at 02:18:34PM +0300, Pasi K?rkk?inen wrote:
> > On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi K?rkk?inen wrote:
> > > > >>
> > > > >
> > > > > Yes, the lid acpi stuff seems to work:
> > > > >
> > > > > lid closed:
> > > > > $ cat /proc/acpi/button/lid/LID/state
> > > > > state: ? ? ?closed
> > > > >
> > > > > lid open:
> > > > > $ cat /proc/acpi/button/lid/LID/state
> > > > > state: ? ? ?open
> > > > >
> > > > > I also verified that the initial lid state is "closed" when
> > > > > the lid has been closed all the time during system startup
> > > > > and only external DVI display is in use.
> > > > >
> > > > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > > > so I can check it during system startup before X starts).
> > > > >
> > > > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > > > 
> > > > Yes.  The LVDS is connected, even if you don't necessarily want to use 
> > > > it.
> > > > 
> > > 
> > > That's what I was thinking of. But good to get confirmation :)
> > > 
> > > > >
> > > > > I think LVDS actually is ON when lid is closed, since I can 
> > > > > immediately
> > > > > see everything when I open the lid.. correct colors etc.
> > > > >
> > > > > So what's the component I should start looking at.. 
> > > > > gnome-power-manager?
> > > > > or something else?
> > > > >
> > > > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > > > gets enabled/turned on, even when the lid is closed.. I think.
> > > > 
> > > > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > > > display policy based on the lid state.
> > > > 
> > > 
> > > Ok. Is there a way to monitor the status of drm from /proc or /sys or 
> > > from somewhere? 
> > > 
> > 
> > Back to this..
> > 
> > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> > but is there a way to monitor the state of the drm/kms outputs from /proc, 
> > /sys or from somewhere? 
> > 
> > I'd like to see the state before X is started, and verify what happens when 
> > GDM is started etc.. 
> > (ie. if outputs are enabled/active or not).
> > 
> 
> Ah, found it:
> 
> $ ls /sys/class/drm/card0
> card0-DVI-D-1card0-LVDS-1  dev power  uevent
> card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> 
> $ cat /sys/class/drm/card0/card0-LVDS-1/status 
> connected
> 
> $ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
> enabled
> 

So I added those to rc.local so that they get executed before GDM..
and I booted up the laptop with the lid closed..

And the result was: lid state "closed", lvds-status "connected" and 
lvds-enabled was "enabled"..

Does that mean Fedora plymouth is doing it wrong,
or is t possible the driver itself always enabled the lvds, even when the lid 
is closed? 

-- Pasi

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 02:18:34PM +0300, Pasi K?rkk?inen wrote:
> On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi K?rkk?inen wrote:
> > > >>
> > > >
> > > > Yes, the lid acpi stuff seems to work:
> > > >
> > > > lid closed:
> > > > $ cat /proc/acpi/button/lid/LID/state
> > > > state: ? ? ?closed
> > > >
> > > > lid open:
> > > > $ cat /proc/acpi/button/lid/LID/state
> > > > state: ? ? ?open
> > > >
> > > > I also verified that the initial lid state is "closed" when
> > > > the lid has been closed all the time during system startup
> > > > and only external DVI display is in use.
> > > >
> > > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > > so I can check it during system startup before X starts).
> > > >
> > > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > > 
> > > Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> > > 
> > 
> > That's what I was thinking of. But good to get confirmation :)
> > 
> > > >
> > > > I think LVDS actually is ON when lid is closed, since I can immediately
> > > > see everything when I open the lid.. correct colors etc.
> > > >
> > > > So what's the component I should start looking at.. gnome-power-manager?
> > > > or something else?
> > > >
> > > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > > gets enabled/turned on, even when the lid is closed.. I think.
> > > 
> > > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > > display policy based on the lid state.
> > > 
> > 
> > Ok. Is there a way to monitor the status of drm from /proc or /sys or from 
> > somewhere? 
> > 
> 
> Back to this..
> 
> so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> but is there a way to monitor the state of the drm/kms outputs from /proc, 
> /sys or from somewhere? 
> 
> I'd like to see the state before X is started, and verify what happens when 
> GDM is started etc.. 
> (ie. if outputs are enabled/active or not).
> 

Ah, found it:

$ ls /sys/class/drm/card0
card0-DVI-D-1card0-LVDS-1  dev power  uevent
card0-HDMI Type A-1  card0-VGA-1   device  subsystem

$ cat /sys/class/drm/card0/card0-LVDS-1/status 
connected

$ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
enabled

$ cat /sys/class/drm/card0/card0-LVDS-1/modes 
1680x1050
1400x1050
1280x1024
1440x900
1280x960
1280x854
1280x800
1280x720
1152x768
1024x768
800x600
848x480
720x480
640x480


-- Pasi

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi K?rkk?inen wrote:
> > >>
> > >
> > > Yes, the lid acpi stuff seems to work:
> > >
> > > lid closed:
> > > $ cat /proc/acpi/button/lid/LID/state
> > > state: ? ? ?closed
> > >
> > > lid open:
> > > $ cat /proc/acpi/button/lid/LID/state
> > > state: ? ? ?open
> > >
> > > I also verified that the initial lid state is "closed" when
> > > the lid has been closed all the time during system startup
> > > and only external DVI display is in use.
> > >
> > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > so I can check it during system startup before X starts).
> > >
> > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > 
> > Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> > 
> 
> That's what I was thinking of. But good to get confirmation :)
> 
> > >
> > > I think LVDS actually is ON when lid is closed, since I can immediately
> > > see everything when I open the lid.. correct colors etc.
> > >
> > > So what's the component I should start looking at.. gnome-power-manager?
> > > or something else?
> > >
> > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > gets enabled/turned on, even when the lid is closed.. I think.
> > 
> > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > display policy based on the lid state.
> > 
> 
> Ok. Is there a way to monitor the status of drm from /proc or /sys or from 
> somewhere? 
> 

Back to this..

so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
but is there a way to monitor the state of the drm/kms outputs from /proc, /sys 
or from somewhere? 

I'd like to see the state before X is started, and verify what happens when GDM 
is started etc.. 
(ie. if outputs are enabled/active or not).

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 03:25:47PM +0300, Pasi Kärkkäinen wrote:
> > > 
> > > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> > > but is there a way to monitor the state of the drm/kms outputs from 
> > > /proc, /sys or from somewhere? 
> > > 
> > > I'd like to see the state before X is started, and verify what happens 
> > > when GDM is started etc.. 
> > > (ie. if outputs are enabled/active or not).
> > > 
> > 
> > Ah, found it:
> > 
> > $ ls /sys/class/drm/card0
> > card0-DVI-D-1card0-LVDS-1  dev power  uevent
> > card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> > 
> > $ cat /sys/class/drm/card0/card0-LVDS-1/status 
> > connected
> > 
> > $ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
> > enabled
> > 
> 
> So I added those to rc.local so that they get executed before GDM..
> and I booted up the laptop with the lid closed..
> 
> And the result was: lid state "closed", lvds-status "connected" and 
> lvds-enabled was "enabled"..
> 
> Does that mean Fedora plymouth is doing it wrong,
> or is t possible the driver itself always enabled the lvds, even when the lid 
> is closed? 
> 

I did some more investigations. I'm currently using Fedora 13 Linux 
2.6.34.6-47.fc13.x86_64 kernel.
I hacked the initrd image to echo debug stuff right after drm modules are 
loaded, 
and *before* plymouth is started (and then sleep for some time so that I have 
time to see the debug values.)

The result was this:

acpi lid/state: closed
lvds-1/status: connected
lvds-1/enabled: enabled

So to me it looks like the problem is in the driver itself..
lvds shouldn't get enabled (turned on) when the lid is closed..

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 02:34:03PM +0300, Pasi Kärkkäinen wrote:
> On Sun, Sep 19, 2010 at 02:18:34PM +0300, Pasi Kärkkäinen wrote:
> > On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi Kärkkäinen wrote:
> > > > >>
> > > > >
> > > > > Yes, the lid acpi stuff seems to work:
> > > > >
> > > > > lid closed:
> > > > > $ cat /proc/acpi/button/lid/LID/state
> > > > > state:      closed
> > > > >
> > > > > lid open:
> > > > > $ cat /proc/acpi/button/lid/LID/state
> > > > > state:      open
> > > > >
> > > > > I also verified that the initial lid state is "closed" when
> > > > > the lid has been closed all the time during system startup
> > > > > and only external DVI display is in use.
> > > > >
> > > > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > > > so I can check it during system startup before X starts).
> > > > >
> > > > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > > > 
> > > > Yes.  The LVDS is connected, even if you don't necessarily want to use 
> > > > it.
> > > > 
> > > 
> > > That's what I was thinking of. But good to get confirmation :)
> > > 
> > > > >
> > > > > I think LVDS actually is ON when lid is closed, since I can 
> > > > > immediately
> > > > > see everything when I open the lid.. correct colors etc.
> > > > >
> > > > > So what's the component I should start looking at.. 
> > > > > gnome-power-manager?
> > > > > or something else?
> > > > >
> > > > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > > > gets enabled/turned on, even when the lid is closed.. I think.
> > > > 
> > > > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > > > display policy based on the lid state.
> > > > 
> > > 
> > > Ok. Is there a way to monitor the status of drm from /proc or /sys or 
> > > from somewhere? 
> > > 
> > 
> > Back to this..
> > 
> > so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> > but is there a way to monitor the state of the drm/kms outputs from /proc, 
> > /sys or from somewhere? 
> > 
> > I'd like to see the state before X is started, and verify what happens when 
> > GDM is started etc.. 
> > (ie. if outputs are enabled/active or not).
> > 
> 
> Ah, found it:
> 
> $ ls /sys/class/drm/card0
> card0-DVI-D-1card0-LVDS-1  dev power  uevent
> card0-HDMI Type A-1  card0-VGA-1   device  subsystem
> 
> $ cat /sys/class/drm/card0/card0-LVDS-1/status 
> connected
> 
> $ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
> enabled
> 

So I added those to rc.local so that they get executed before GDM..
and I booted up the laptop with the lid closed..

And the result was: lid state "closed", lvds-status "connected" and 
lvds-enabled was "enabled"..

Does that mean Fedora plymouth is doing it wrong,
or is t possible the driver itself always enabled the lvds, even when the lid 
is closed? 

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi Kärkkäinen wrote:
> > >>
> > >
> > > Yes, the lid acpi stuff seems to work:
> > >
> > > lid closed:
> > > $ cat /proc/acpi/button/lid/LID/state
> > > state:      closed
> > >
> > > lid open:
> > > $ cat /proc/acpi/button/lid/LID/state
> > > state:      open
> > >
> > > I also verified that the initial lid state is "closed" when
> > > the lid has been closed all the time during system startup
> > > and only external DVI display is in use.
> > >
> > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > so I can check it during system startup before X starts).
> > >
> > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > 
> > Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> > 
> 
> That's what I was thinking of. But good to get confirmation :)
> 
> > >
> > > I think LVDS actually is ON when lid is closed, since I can immediately
> > > see everything when I open the lid.. correct colors etc.
> > >
> > > So what's the component I should start looking at.. gnome-power-manager?
> > > or something else?
> > >
> > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > gets enabled/turned on, even when the lid is closed.. I think.
> > 
> > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > display policy based on the lid state.
> > 
> 
> Ok. Is there a way to monitor the status of drm from /proc or /sys or from 
> somewhere? 
> 

Back to this..

so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
but is there a way to monitor the state of the drm/kms outputs from /proc, /sys 
or from somewhere? 

I'd like to see the state before X is started, and verify what happens when GDM 
is started etc.. 
(ie. if outputs are enabled/active or not).

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Sun, Sep 19, 2010 at 02:18:34PM +0300, Pasi Kärkkäinen wrote:
> On Tue, Jul 27, 2010 at 11:41:12AM +0300, Pasi Kärkkäinen wrote:
> > > >>
> > > >
> > > > Yes, the lid acpi stuff seems to work:
> > > >
> > > > lid closed:
> > > > $ cat /proc/acpi/button/lid/LID/state
> > > > state:      closed
> > > >
> > > > lid open:
> > > > $ cat /proc/acpi/button/lid/LID/state
> > > > state:      open
> > > >
> > > > I also verified that the initial lid state is "closed" when
> > > > the lid has been closed all the time during system startup
> > > > and only external DVI display is in use.
> > > >
> > > > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > > > so I can check it during system startup before X starts).
> > > >
> > > > When the lid is closed xrandr says "LVDS connected", is that correct?
> > > 
> > > Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> > > 
> > 
> > That's what I was thinking of. But good to get confirmation :)
> > 
> > > >
> > > > I think LVDS actually is ON when lid is closed, since I can immediately
> > > > see everything when I open the lid.. correct colors etc.
> > > >
> > > > So what's the component I should start looking at.. gnome-power-manager?
> > > > or something else?
> > > >
> > > > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > > > gets enabled/turned on, even when the lid is closed.. I think.
> > > 
> > > Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> > > display policy based on the lid state.
> > > 
> > 
> > Ok. Is there a way to monitor the status of drm from /proc or /sys or from 
> > somewhere? 
> > 
> 
> Back to this..
> 
> so "/proc/acpi/button/lid/LID/state" seems to work properly on my laptop,
> but is there a way to monitor the state of the drm/kms outputs from /proc, 
> /sys or from somewhere? 
> 
> I'd like to see the state before X is started, and verify what happens when 
> GDM is started etc.. 
> (ie. if outputs are enabled/active or not).
> 

Ah, found it:

$ ls /sys/class/drm/card0
card0-DVI-D-1card0-LVDS-1  dev power  uevent
card0-HDMI Type A-1  card0-VGA-1   device  subsystem

$ cat /sys/class/drm/card0/card0-LVDS-1/status 
connected

$ cat /sys/class/drm/card0/card0-LVDS-1/enabled 
enabled

$ cat /sys/class/drm/card0/card0-LVDS-1/modes 
1680x1050
1400x1050
1280x1024
1440x900
1280x960
1280x854
1280x800
1280x720
1152x768
1024x768
800x600
848x480
720x480
640x480


-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

DRI/DRM profiling for performance analysis?

[Pasi Kärkkäinen]

On Mon, Aug 16, 2010 at 09:15:18PM -0700, Eric Anholt wrote:
> On Mon, 16 Aug 2010 10:22:35 +0300, Pasi K?rkk?inen  wrote:
> > Hello,
> > 
> > Do we currently have a method of profiling DRI/DRM drivers?
> > 
> > I was thinking that it would be interesting to:
> > 
> > 1) Execute a benchmark, or some "timedemo" of a game
> > 2) See how many times each dri/drm driver function is called, 
> >maybe top 20 most often called functions, 
> >and the total cpu time used for those functions.
> > 
> > So you could see that:
> > 
> > 1) some function is called often, but it doesn't take much total cpu time.
> > 2) some function is called just a couple of times, but it takes a lot of 
> > cpu time.
> > 
> > And everything in between.. would be good hints to use for optimizing the 
> > apps/drivers,
> > and for comparison between different versions..
> > 
> > Does this make sense? 
> 
> The tool to use is called "sysprof" and is ridiculously easy to use (on
> 32-bit x86).  Click start, click stop, see where time was spent, go fix
> that.

Thanks!

That might make interesting addition to things like Phoronix benchmarks..
to compare the differences between driver versions.

-- Pasi

Re: DRI/DRM profiling for performance analysis?

[Pasi Kärkkäinen]

On Mon, Aug 16, 2010 at 09:15:18PM -0700, Eric Anholt wrote:
> On Mon, 16 Aug 2010 10:22:35 +0300, Pasi Kärkkäinen  wrote:
> > Hello,
> > 
> > Do we currently have a method of profiling DRI/DRM drivers?
> > 
> > I was thinking that it would be interesting to:
> > 
> > 1) Execute a benchmark, or some "timedemo" of a game
> > 2) See how many times each dri/drm driver function is called, 
> >maybe top 20 most often called functions, 
> >and the total cpu time used for those functions.
> > 
> > So you could see that:
> > 
> > 1) some function is called often, but it doesn't take much total cpu time.
> > 2) some function is called just a couple of times, but it takes a lot of 
> > cpu time.
> > 
> > And everything in between.. would be good hints to use for optimizing the 
> > apps/drivers,
> > and for comparison between different versions..
> > 
> > Does this make sense? 
> 
> The tool to use is called "sysprof" and is ridiculously easy to use (on
> 32-bit x86).  Click start, click stop, see where time was spent, go fix
> that.

Thanks!

That might make interesting addition to things like Phoronix benchmarks..
to compare the differences between driver versions.

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

DRI/DRM profiling for performance analysis?

[Pasi Kärkkäinen]

Hello,

Do we currently have a method of profiling DRI/DRM drivers?

I was thinking that it would be interesting to:

1) Execute a benchmark, or some "timedemo" of a game
2) See how many times each dri/drm driver function is called, 
   maybe top 20 most often called functions, 
   and the total cpu time used for those functions.

So you could see that:

1) some function is called often, but it doesn't take much total cpu time.
2) some function is called just a couple of times, but it takes a lot of cpu 
time.

And everything in between.. would be good hints to use for optimizing the 
apps/drivers,
and for comparison between different versions..

Does this make sense? 

-- Pasi

DRI/DRM profiling for performance analysis?

[Pasi Kärkkäinen]

Hello,

Do we currently have a method of profiling DRI/DRM drivers?

I was thinking that it would be interesting to:

1) Execute a benchmark, or some "timedemo" of a game
2) See how many times each dri/drm driver function is called, 
   maybe top 20 most often called functions, 
   and the total cpu time used for those functions.

So you could see that:

1) some function is called often, but it doesn't take much total cpu time.
2) some function is called just a couple of times, but it takes a lot of cpu 
time.

And everything in between.. would be good hints to use for optimizing the 
apps/drivers,
and for comparison between different versions..

Does this make sense? 

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 26, 2010 at 05:13:30PM -0400, Alex Deucher wrote:
> On Mon, Jul 26, 2010 at 3:42 PM, Pasi K?rkk?inen  wrote:
> > On Mon, Jul 12, 2010 at 01:37:28PM -0400, Alex Deucher wrote:
> >> >> >>
> >> >> >
> >> >> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) 
> >> >> > applied
> >> >> > my system mostly works now, but here's a summary about the problem I 
> >> >> > still have
> >> >> > with the lid detection:
> >> >> >
> >> >> > - I boot up the laptop with lid closed (LVDS inactive) so there's 
> >> >> > only external
> >> >> > DVI display connected. Kernel boot messages show up on the external 
> >> >> > DVI display,
> >> >> > and GDM login prompt appears on the external DVI display. All fine so 
> >> >> > far.
> >> >> >
> >> >> > - The actual problem: when X starts gnome panel etc show up on the 
> >> >> > internal LVDS
> >> >> > display, which I can't see at all since the lid is closed! So those 
> >> >> > should go to the
> >> >> > external DVI display only.. LVDS should be disconnected or inactive 
> >> >> > or something..
> >> >> >
> >> >> > Any pointers appreciated where to look at in the source.. I can do 
> >> >> > some debugging.
> >> >>
> >> >> Your desktop session manager should check the lid status when it loads
> >> >> and attempt to do the right thing if there is an external monitor
> >> >> detected.
> >> >>
> >> >
> >> > Ok.
> >> > So you think it's not a bug in the lid detection?
> >>
> >> Not sure. ?That's handled by apci, not the video driver. ?You can
> >> check it the lid is producing proper events by running:
> >> cat /proc/acpi/button/lid/LID/state
> >> with the lid open and closed. ?The desktop manager decides what the
> >> policy is for the lid (blank display, suspend, turn off the connector,
> >> etc.). ?It should also take into account other connected outputs, but
> >> I don't think it handles that too well at the moment.
> >>
> >
> > Yes, the lid acpi stuff seems to work:
> >
> > lid closed:
> > $ cat /proc/acpi/button/lid/LID/state
> > state: ? ? ?closed
> >
> > lid open:
> > $ cat /proc/acpi/button/lid/LID/state
> > state: ? ? ?open
> >
> > I also verified that the initial lid state is "closed" when
> > the lid has been closed all the time during system startup
> > and only external DVI display is in use.
> >
> > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > so I can check it during system startup before X starts).
> >
> > When the lid is closed xrandr says "LVDS connected", is that correct?
> 
> Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> 

That's what I was thinking of. But good to get confirmation :)

> >
> > I think LVDS actually is ON when lid is closed, since I can immediately
> > see everything when I open the lid.. correct colors etc.
> >
> > So what's the component I should start looking at.. gnome-power-manager?
> > or something else?
> >
> > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > gets enabled/turned on, even when the lid is closed.. I think.
> 
> Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> display policy based on the lid state.
> 

Ok. Is there a way to monitor the status of drm from /proc or /sys or from 
somewhere? 

I guess I'll have to start reading GDM code to check what it does..

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 26, 2010 at 05:13:30PM -0400, Alex Deucher wrote:
> On Mon, Jul 26, 2010 at 3:42 PM, Pasi Kärkkäinen  wrote:
> > On Mon, Jul 12, 2010 at 01:37:28PM -0400, Alex Deucher wrote:
> >> >> >>
> >> >> >
> >> >> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) 
> >> >> > applied
> >> >> > my system mostly works now, but here's a summary about the problem I 
> >> >> > still have
> >> >> > with the lid detection:
> >> >> >
> >> >> > - I boot up the laptop with lid closed (LVDS inactive) so there's 
> >> >> > only external
> >> >> > DVI display connected. Kernel boot messages show up on the external 
> >> >> > DVI display,
> >> >> > and GDM login prompt appears on the external DVI display. All fine so 
> >> >> > far.
> >> >> >
> >> >> > - The actual problem: when X starts gnome panel etc show up on the 
> >> >> > internal LVDS
> >> >> > display, which I can't see at all since the lid is closed! So those 
> >> >> > should go to the
> >> >> > external DVI display only.. LVDS should be disconnected or inactive 
> >> >> > or something..
> >> >> >
> >> >> > Any pointers appreciated where to look at in the source.. I can do 
> >> >> > some debugging.
> >> >>
> >> >> Your desktop session manager should check the lid status when it loads
> >> >> and attempt to do the right thing if there is an external monitor
> >> >> detected.
> >> >>
> >> >
> >> > Ok.
> >> > So you think it's not a bug in the lid detection?
> >>
> >> Not sure.  That's handled by apci, not the video driver.  You can
> >> check it the lid is producing proper events by running:
> >> cat /proc/acpi/button/lid/LID/state
> >> with the lid open and closed.  The desktop manager decides what the
> >> policy is for the lid (blank display, suspend, turn off the connector,
> >> etc.).  It should also take into account other connected outputs, but
> >> I don't think it handles that too well at the moment.
> >>
> >
> > Yes, the lid acpi stuff seems to work:
> >
> > lid closed:
> > $ cat /proc/acpi/button/lid/LID/state
> > state:      closed
> >
> > lid open:
> > $ cat /proc/acpi/button/lid/LID/state
> > state:      open
> >
> > I also verified that the initial lid state is "closed" when
> > the lid has been closed all the time during system startup
> > and only external DVI display is in use.
> >
> > (I modified /etc/rc5.d/S01sysstat to sleep+print+sleep
> > so I can check it during system startup before X starts).
> >
> > When the lid is closed xrandr says "LVDS connected", is that correct?
> 
> Yes.  The LVDS is connected, even if you don't necessarily want to use it.
> 

That's what I was thinking of. But good to get confirmation :)

> >
> > I think LVDS actually is ON when lid is closed, since I can immediately
> > see everything when I open the lid.. correct colors etc.
> >
> > So what's the component I should start looking at.. gnome-power-manager?
> > or something else?
> >
> > Actually.. I just noticed that already in GDM prompt the internal LVDS
> > gets enabled/turned on, even when the lid is closed.. I think.
> 
> Yes, it's up to to gdm, gnome-power-manager, etc. to decide the
> display policy based on the lid state.
> 

Ok. Is there a way to monitor the status of drm from /proc or /sys or from 
somewhere? 

I guess I'll have to start reading GDM code to check what it does..

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 12, 2010 at 01:37:28PM -0400, Alex Deucher wrote:
> >> >>
> >> >
> >> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) 
> >> > applied
> >> > my system mostly works now, but here's a summary about the problem I 
> >> > still have
> >> > with the lid detection:
> >> >
> >> > - I boot up the laptop with lid closed (LVDS inactive) so there's only 
> >> > external
> >> > DVI display connected. Kernel boot messages show up on the external DVI 
> >> > display,
> >> > and GDM login prompt appears on the external DVI display. All fine so 
> >> > far.
> >> >
> >> > - The actual problem: when X starts gnome panel etc show up on the 
> >> > internal LVDS
> >> > display, which I can't see at all since the lid is closed! So those 
> >> > should go to the
> >> > external DVI display only.. LVDS should be disconnected or inactive or 
> >> > something..
> >> >
> >> > Any pointers appreciated where to look at in the source.. I can do some 
> >> > debugging.
> >>
> >> Your desktop session manager should check the lid status when it loads
> >> and attempt to do the right thing if there is an external monitor
> >> detected.
> >>
> >
> > Ok.
> > So you think it's not a bug in the lid detection?
> 
> Not sure.  That's handled by apci, not the video driver.  You can
> check it the lid is producing proper events by running:
> cat /proc/acpi/button/lid/LID/state
> with the lid open and closed.  The desktop manager decides what the
> policy is for the lid (blank display, suspend, turn off the connector,
> etc.).  It should also take into account other connected outputs, but
> I don't think it handles that too well at the moment.
> 

Yes, the lid acpi stuff seems to work:

lid closed:
$ cat /proc/acpi/button/lid/LID/state 
state:  closed

lid open:
$ cat /proc/acpi/button/lid/LID/state 
state:  open

I also verified that the initial lid state is "closed" when 
the lid has been closed all the time during system startup 
and only external DVI display is in use. 

(I modified /etc/rc5.d/S01sysstat to sleep+print+sleep 
so I can check it during system startup before X starts).

When the lid is closed xrandr says "LVDS connected", is that correct? 

I think LVDS actually is ON when lid is closed, since I can immediately 
see everything when I open the lid.. correct colors etc.

So what's the component I should start looking at.. gnome-power-manager? 
or something else? 

Actually.. I just noticed that already in GDM prompt the internal LVDS
gets enabled/turned on, even when the lid is closed.. I think.

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 12, 2010 at 01:37:28PM -0400, Alex Deucher wrote:
> >> >>
> >> >
> >> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) 
> >> > applied
> >> > my system mostly works now, but here's a summary about the problem I 
> >> > still have
> >> > with the lid detection:
> >> >
> >> > - I boot up the laptop with lid closed (LVDS inactive) so there's only 
> >> > external
> >> > DVI display connected. Kernel boot messages show up on the external DVI 
> >> > display,
> >> > and GDM login prompt appears on the external DVI display. All fine so 
> >> > far.
> >> >
> >> > - The actual problem: when X starts gnome panel etc show up on the 
> >> > internal LVDS
> >> > display, which I can't see at all since the lid is closed! So those 
> >> > should go to the
> >> > external DVI display only.. LVDS should be disconnected or inactive or 
> >> > something..
> >> >
> >> > Any pointers appreciated where to look at in the source.. I can do some 
> >> > debugging.
> >>
> >> Your desktop session manager should check the lid status when it loads
> >> and attempt to do the right thing if there is an external monitor
> >> detected.
> >>
> >
> > Ok.
> > So you think it's not a bug in the lid detection?
> 
> Not sure.  That's handled by apci, not the video driver.  You can
> check it the lid is producing proper events by running:
> cat /proc/acpi/button/lid/LID/state
> with the lid open and closed.  The desktop manager decides what the
> policy is for the lid (blank display, suspend, turn off the connector,
> etc.).  It should also take into account other connected outputs, but
> I don't think it handles that too well at the moment.
> 

Yes, the lid acpi stuff seems to work:

lid closed:
$ cat /proc/acpi/button/lid/LID/state 
state:  closed

lid open:
$ cat /proc/acpi/button/lid/LID/state 
state:  open

I also verified that the initial lid state is "closed" when 
the lid has been closed all the time during system startup 
and only external DVI display is in use. 

(I modified /etc/rc5.d/S01sysstat to sleep+print+sleep 
so I can check it during system startup before X starts).

When the lid is closed xrandr says "LVDS connected", is that correct? 

I think LVDS actually is ON when lid is closed, since I can immediately 
see everything when I open the lid.. correct colors etc.

So what's the component I should start looking at.. gnome-power-manager? 
or something else? 

Actually.. I just noticed that already in GDM prompt the internal LVDS
gets enabled/turned on, even when the lid is closed.. I think.

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: fix shared ddc harder

[Pasi Kärkkäinen]

On Thu, Jul 22, 2010 at 03:28:32PM +0300, Pasi K?rkk?inen wrote:
> On Tue, Jul 20, 2010 at 11:27:54AM -0400, Alex Deucher wrote:
> > This fixes a regression caused by b2ea4aa67bfd084834edd070e0a4a47857d6db59
> > due to the way shared ddc with multiple digital connectors was handled.
> > 
> 
> I guess I should verify this patch still works for me..
> 

I applied this patch, and everything still seems to work ok :)

-- Pasi

> 
> > You generally have two cases where DDC lines are shared:
> > - HDMI + VGA
> > - HDMI + DVI-D
> > 
> > HDMI + VGA is easy to deal with because you can check the EDID for the
> > to see if the attached monitor is digital.  A shared DDC line with two
> > digital connectors is more complex.  You can't use the hdmi bits in the
> > EDID since they may not be there with DVI<->HDMI adapters.  In this case
> > all we can do is check the HPD pins to see which is connected as we have
> > no way of knowing using the EDID.
> > 
> > Reported-by: trapdoor6 at gmail.com
> > Signed-off-by: Alex Deucher 
> > Cc: stable at kernel.org
> > ---
> >  drivers/gpu/drm/radeon/radeon_connectors.c |   23 +--
> >  1 files changed, 9 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> > b/drivers/gpu/drm/radeon/radeon_connectors.c
> > index f58f8bd..adccbc2 100644
> > --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> > +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> > @@ -771,14 +771,14 @@ static enum drm_connector_status 
> > radeon_dvi_detect(struct drm_connector *connect
> > } else
> > ret = connector_status_connected;
> >  
> > -   /* multiple connectors on the same encoder with the 
> > same ddc line
> > -* This tends to be HDMI and DVI on the same encoder 
> > with the
> > -* same ddc line.  If the edid says HDMI, consider the 
> > HDMI port
> > -* connected and the DVI port disconnected.  If the 
> > edid doesn't
> > -* say HDMI, vice versa.
> > +   /* This gets complicated.  We have boards with VGA + 
> > HDMI with a
> > +* shared DDC line and we have boards with DVI-D + HDMI 
> > with a shared
> > +* DDC line.  The latter is more complex because with 
> > DVI<->HDMI adapters
> > +* you don't really know what's connected to which port 
> > as both are digital.
> >  */
> > if (radeon_connector->shared_ddc && (ret == 
> > connector_status_connected)) {
> > struct drm_device *dev = connector->dev;
> > +   struct radeon_device *rdev = dev->dev_private;
> > struct drm_connector *list_connector;
> > struct radeon_connector *list_radeon_connector;
> > list_for_each_entry(list_connector, 
> > &dev->mode_config.connector_list, head) {
> > @@ -788,15 +788,10 @@ static enum drm_connector_status 
> > radeon_dvi_detect(struct drm_connector *connect
> > if (list_radeon_connector->shared_ddc &&
> > 
> > (list_radeon_connector->ddc_bus->rec.i2c_id ==
> >  
> > radeon_connector->ddc_bus->rec.i2c_id)) {
> > -   if 
> > (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> > -   if 
> > (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> > -   
> > kfree(radeon_connector->edid);
> > -   
> > radeon_connector->edid = NULL;
> > -   ret = 
> > connector_status_disconnected;
> > -   }
> > -   } else {
> > -   if 
> > ((connector->connector_type == DRM_MODE_CONNECTOR_HDMIA) ||
> > -   
> > (connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)) {
> > +   /* cases where both connectors 
> > are digital */
> > +   if 
> > (list_connector->connector_type != DRM_MODE_CONNECTOR_VGA) {
> > +   /* hpd is our only 
> > option in this case */
> > +   if 
> > (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
> > 
> > kfree(radeon_connector->edid);
> > 
> > radeon_connector->edid = NULL;
> >

Re: [PATCH] drm/radeon/kms: fix shared ddc harder

[Pasi Kärkkäinen]

On Thu, Jul 22, 2010 at 03:28:32PM +0300, Pasi Kärkkäinen wrote:
> On Tue, Jul 20, 2010 at 11:27:54AM -0400, Alex Deucher wrote:
> > This fixes a regression caused by b2ea4aa67bfd084834edd070e0a4a47857d6db59
> > due to the way shared ddc with multiple digital connectors was handled.
> > 
> 
> I guess I should verify this patch still works for me..
> 

I applied this patch, and everything still seems to work ok :)

-- Pasi

> 
> > You generally have two cases where DDC lines are shared:
> > - HDMI + VGA
> > - HDMI + DVI-D
> > 
> > HDMI + VGA is easy to deal with because you can check the EDID for the
> > to see if the attached monitor is digital.  A shared DDC line with two
> > digital connectors is more complex.  You can't use the hdmi bits in the
> > EDID since they may not be there with DVI<->HDMI adapters.  In this case
> > all we can do is check the HPD pins to see which is connected as we have
> > no way of knowing using the EDID.
> > 
> > Reported-by: trapdo...@gmail.com
> > Signed-off-by: Alex Deucher 
> > Cc: sta...@kernel.org
> > ---
> >  drivers/gpu/drm/radeon/radeon_connectors.c |   23 +--
> >  1 files changed, 9 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> > b/drivers/gpu/drm/radeon/radeon_connectors.c
> > index f58f8bd..adccbc2 100644
> > --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> > +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> > @@ -771,14 +771,14 @@ static enum drm_connector_status 
> > radeon_dvi_detect(struct drm_connector *connect
> > } else
> > ret = connector_status_connected;
> >  
> > -   /* multiple connectors on the same encoder with the 
> > same ddc line
> > -* This tends to be HDMI and DVI on the same encoder 
> > with the
> > -* same ddc line.  If the edid says HDMI, consider the 
> > HDMI port
> > -* connected and the DVI port disconnected.  If the 
> > edid doesn't
> > -* say HDMI, vice versa.
> > +   /* This gets complicated.  We have boards with VGA + 
> > HDMI with a
> > +* shared DDC line and we have boards with DVI-D + HDMI 
> > with a shared
> > +* DDC line.  The latter is more complex because with 
> > DVI<->HDMI adapters
> > +* you don't really know what's connected to which port 
> > as both are digital.
> >  */
> > if (radeon_connector->shared_ddc && (ret == 
> > connector_status_connected)) {
> > struct drm_device *dev = connector->dev;
> > +   struct radeon_device *rdev = dev->dev_private;
> > struct drm_connector *list_connector;
> > struct radeon_connector *list_radeon_connector;
> > list_for_each_entry(list_connector, 
> > &dev->mode_config.connector_list, head) {
> > @@ -788,15 +788,10 @@ static enum drm_connector_status 
> > radeon_dvi_detect(struct drm_connector *connect
> > if (list_radeon_connector->shared_ddc &&
> > 
> > (list_radeon_connector->ddc_bus->rec.i2c_id ==
> >  
> > radeon_connector->ddc_bus->rec.i2c_id)) {
> > -   if 
> > (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> > -   if 
> > (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> > -   
> > kfree(radeon_connector->edid);
> > -   
> > radeon_connector->edid = NULL;
> > -   ret = 
> > connector_status_disconnected;
> > -   }
> > -   } else {
> > -   if 
> > ((connector->connector_type == DRM_MODE_CONNECTOR_HDMIA) ||
> > -   
> > (connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)) {
> > + 

[PATCH] drm/radeon/kms: fix shared ddc harder

[Pasi Kärkkäinen]

On Tue, Jul 20, 2010 at 11:27:54AM -0400, Alex Deucher wrote:
> This fixes a regression caused by b2ea4aa67bfd084834edd070e0a4a47857d6db59
> due to the way shared ddc with multiple digital connectors was handled.
> 

I guess I should verify this patch still works for me..

-- Pasi

> You generally have two cases where DDC lines are shared:
> - HDMI + VGA
> - HDMI + DVI-D
> 
> HDMI + VGA is easy to deal with because you can check the EDID for the
> to see if the attached monitor is digital.  A shared DDC line with two
> digital connectors is more complex.  You can't use the hdmi bits in the
> EDID since they may not be there with DVI<->HDMI adapters.  In this case
> all we can do is check the HPD pins to see which is connected as we have
> no way of knowing using the EDID.
> 
> Reported-by: trapdoor6 at gmail.com
> Signed-off-by: Alex Deucher 
> Cc: stable at kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_connectors.c |   23 +--
>  1 files changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index f58f8bd..adccbc2 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -771,14 +771,14 @@ static enum drm_connector_status 
> radeon_dvi_detect(struct drm_connector *connect
>   } else
>   ret = connector_status_connected;
>  
> - /* multiple connectors on the same encoder with the 
> same ddc line
> -  * This tends to be HDMI and DVI on the same encoder 
> with the
> -  * same ddc line.  If the edid says HDMI, consider the 
> HDMI port
> -  * connected and the DVI port disconnected.  If the 
> edid doesn't
> -  * say HDMI, vice versa.
> + /* This gets complicated.  We have boards with VGA + 
> HDMI with a
> +  * shared DDC line and we have boards with DVI-D + HDMI 
> with a shared
> +  * DDC line.  The latter is more complex because with 
> DVI<->HDMI adapters
> +  * you don't really know what's connected to which port 
> as both are digital.
>*/
>   if (radeon_connector->shared_ddc && (ret == 
> connector_status_connected)) {
>   struct drm_device *dev = connector->dev;
> + struct radeon_device *rdev = dev->dev_private;
>   struct drm_connector *list_connector;
>   struct radeon_connector *list_radeon_connector;
>   list_for_each_entry(list_connector, 
> &dev->mode_config.connector_list, head) {
> @@ -788,15 +788,10 @@ static enum drm_connector_status 
> radeon_dvi_detect(struct drm_connector *connect
>   if (list_radeon_connector->shared_ddc &&
>   
> (list_radeon_connector->ddc_bus->rec.i2c_id ==
>
> radeon_connector->ddc_bus->rec.i2c_id)) {
> - if 
> (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> - if 
> (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> - 
> kfree(radeon_connector->edid);
> - 
> radeon_connector->edid = NULL;
> - ret = 
> connector_status_disconnected;
> - }
> - } else {
> - if 
> ((connector->connector_type == DRM_MODE_CONNECTOR_HDMIA) ||
> - 
> (connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)) {
> + /* cases where both connectors 
> are digital */
> + if 
> (list_connector->connector_type != DRM_MODE_CONNECTOR_VGA) {
> + /* hpd is our only 
> option in this case */
> + if 
> (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
>   
> kfree(radeon_connector->edid);
>   
> radeon_connector->edid = NULL;
>   ret = 
> connector_status_disconnected;
> -- 
> 1.7.1.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: fix shared ddc harder

[Pasi Kärkkäinen]

On Tue, Jul 20, 2010 at 11:27:54AM -0400, Alex Deucher wrote:
> This fixes a regression caused by b2ea4aa67bfd084834edd070e0a4a47857d6db59
> due to the way shared ddc with multiple digital connectors was handled.
> 

I guess I should verify this patch still works for me..

-- Pasi

> You generally have two cases where DDC lines are shared:
> - HDMI + VGA
> - HDMI + DVI-D
> 
> HDMI + VGA is easy to deal with because you can check the EDID for the
> to see if the attached monitor is digital.  A shared DDC line with two
> digital connectors is more complex.  You can't use the hdmi bits in the
> EDID since they may not be there with DVI<->HDMI adapters.  In this case
> all we can do is check the HPD pins to see which is connected as we have
> no way of knowing using the EDID.
> 
> Reported-by: trapdo...@gmail.com
> Signed-off-by: Alex Deucher 
> Cc: sta...@kernel.org
> ---
>  drivers/gpu/drm/radeon/radeon_connectors.c |   23 +--
>  1 files changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index f58f8bd..adccbc2 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -771,14 +771,14 @@ static enum drm_connector_status 
> radeon_dvi_detect(struct drm_connector *connect
>   } else
>   ret = connector_status_connected;
>  
> - /* multiple connectors on the same encoder with the 
> same ddc line
> -  * This tends to be HDMI and DVI on the same encoder 
> with the
> -  * same ddc line.  If the edid says HDMI, consider the 
> HDMI port
> -  * connected and the DVI port disconnected.  If the 
> edid doesn't
> -  * say HDMI, vice versa.
> + /* This gets complicated.  We have boards with VGA + 
> HDMI with a
> +  * shared DDC line and we have boards with DVI-D + HDMI 
> with a shared
> +  * DDC line.  The latter is more complex because with 
> DVI<->HDMI adapters
> +  * you don't really know what's connected to which port 
> as both are digital.
>*/
>   if (radeon_connector->shared_ddc && (ret == 
> connector_status_connected)) {
>   struct drm_device *dev = connector->dev;
> + struct radeon_device *rdev = dev->dev_private;
>   struct drm_connector *list_connector;
>   struct radeon_connector *list_radeon_connector;
>   list_for_each_entry(list_connector, 
> &dev->mode_config.connector_list, head) {
> @@ -788,15 +788,10 @@ static enum drm_connector_status 
> radeon_dvi_detect(struct drm_connector *connect
>   if (list_radeon_connector->shared_ddc &&
>   
> (list_radeon_connector->ddc_bus->rec.i2c_id ==
>
> radeon_connector->ddc_bus->rec.i2c_id)) {
> - if 
> (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> - if 
> (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> - 
> kfree(radeon_connector->edid);
> - 
> radeon_connector->edid = NULL;
> - ret = 
> connector_status_disconnected;
> - }
> - } else {
> - if 
> ((connector->connector_type == DRM_MODE_CONNECTOR_HDMIA) ||
> - 
> (connector->connector_type == DRM_MODE_CONNECTOR_HDMIB)) {
> + /* cases where both connectors 
> are digital */
> + if 
> (list_connector->connector_type != DRM_MODE_CONNECTOR_VGA) {
> + /* hpd is our only 
> option in this case */
> + if 
> (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
>   
> kfree(radeon_connector->edid);
>   
> radeon_connector->edid = NULL;
>   ret = 
> connector_status_disconnected;
> -- 
> 1.7.1.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 12, 2010 at 10:48:08AM -0400, Alex Deucher wrote:
> On Mon, Jul 12, 2010 at 7:53 AM, Pasi K?rkk?inen  wrote:
> > On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
> >> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez  >> riseup.net> wrote:
> >> > Jerome Glisse  writes:
> >> >
> >> >> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi K?rkk?inen wrote:
> >> >>> Hello,
> >> >>>
> >> >>> After fixing the dvi/hdmi detection problem I now have another problem
> >> >>> with the HP EliteBook 8530p, which has Radeon 3650HD adapter.
> >> >>>
> >> >>> Here's a summary of the environment:
> >> >>>
> >> >>> ? ? ?- laptop connected to a docking station.
> >> >>> ? ? ?- external display in use, connected with DVI to the dock.
> >> >>> ? ? ?- laptop lid closed, so internal LVDS display is not used.
> >> >>>
> >> >>> Now, when I start the laptop, I can see the BIOS and grub on the 
> >> >>> external DVI display.
> >> >>> All fine so far. I select the Fedora 13 kernel, and Linux starts. I 
> >> >>> see the Fedora
> >> >>> graphical boot on the external DVI display, just like it should be. 
> >> >>> GDM login prompt
> >> >>> appears on the external DVI display, still everything fine.
> >> >>>
> >> >>> And then it goes wrong. After I login to X, the external display only 
> >> >>> shows the background
> >> >>> picture.. it turns out the desktop stuff has been started to the 
> >> >>> internal LVDS display,
> >> >>> which shouldn't be used at all since the laptop lid is closed!!
> >> >>>
> >> >>> When the laptop lid is closed, and external display is connected, I 
> >> >>> want to use only the external display..
> >> >>>
> >> >>> Any ideas how to troubleshoot this one?
> >>
> >> Does it work ok if you boot up without the external display connected
> >> and then connect and enable the secondary display after you've logged
> >> in?
> >>
> >
> > I just tried this.
> >
> > I boot up the laptop with lid open, so ONLY the internal LVDS is active
> > (DVI cable disconnected), and I get the GDM login prompt on the internal 
> > LVDS.
> >
> > Then I plug in the external DVI display, and the external display
> > gets automatically active when X starts. Gnome panel etc are on the 
> > internal LVDS,
> > external DVI display only has the background image and nothing else.
> >
> > So that works as expected. No problems there.
> >
> >> ?I have a similar issue here; ?I think it's an issue with rhgb and
> >> starting X. ?If I boot with an external display, the entire plymouth
> >> load sequence works fine, but then when X starts the external display
> >> goes blank and the internal display hangs on the plymouth screen. ?On
> >> a related note, if I close the lid and turn off the LVDS output, gpm
> >> never blanks the external monitor. ?I have to manually force dpms with
> >> xset.
> >>
> >
> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
> > my system mostly works now, but here's a summary about the problem I still 
> > have
> > with the lid detection:
> >
> > - I boot up the laptop with lid closed (LVDS inactive) so there's only 
> > external
> > DVI display connected. Kernel boot messages show up on the external DVI 
> > display,
> > and GDM login prompt appears on the external DVI display. All fine so far.
> >
> > - The actual problem: when X starts gnome panel etc show up on the internal 
> > LVDS
> > display, which I can't see at all since the lid is closed! So those should 
> > go to the
> > external DVI display only.. LVDS should be disconnected or inactive or 
> > something..
> >
> > Any pointers appreciated where to look at in the source.. I can do some 
> > debugging.
> 
> Your desktop session manager should check the lid status when it loads
> and attempt to do the right thing if there is an external monitor
> detected.
> 

Ok.
So you think it's not a bug in the lid detection? 

-- Pasi

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez  
> wrote:
> > Jerome Glisse  writes:
> >
> >> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi K?rkk?inen wrote:
> >>> Hello,
> >>>
> >>> After fixing the dvi/hdmi detection problem I now have another problem
> >>> with the HP EliteBook 8530p, which has Radeon 3650HD adapter.
> >>>
> >>> Here's a summary of the environment:
> >>>
> >>> ? ? ?- laptop connected to a docking station.
> >>> ? ? ?- external display in use, connected with DVI to the dock.
> >>> ? ? ?- laptop lid closed, so internal LVDS display is not used.
> >>>
> >>> Now, when I start the laptop, I can see the BIOS and grub on the external 
> >>> DVI display.
> >>> All fine so far. I select the Fedora 13 kernel, and Linux starts. I see 
> >>> the Fedora
> >>> graphical boot on the external DVI display, just like it should be. GDM 
> >>> login prompt
> >>> appears on the external DVI display, still everything fine.
> >>>
> >>> And then it goes wrong. After I login to X, the external display only 
> >>> shows the background
> >>> picture.. it turns out the desktop stuff has been started to the internal 
> >>> LVDS display,
> >>> which shouldn't be used at all since the laptop lid is closed!!
> >>>
> >>> When the laptop lid is closed, and external display is connected, I want 
> >>> to use only the external display..
> >>>
> >>> Any ideas how to troubleshoot this one?
> 
> Does it work ok if you boot up without the external display connected
> and then connect and enable the secondary display after you've logged
> in?
>

I just tried this.

I boot up the laptop with lid open, so ONLY the internal LVDS is active 
(DVI cable disconnected), and I get the GDM login prompt on the internal LVDS.

Then I plug in the external DVI display, and the external display
gets automatically active when X starts. Gnome panel etc are on the internal 
LVDS,
external DVI display only has the background image and nothing else.

So that works as expected. No problems there.

>  I have a similar issue here;  I think it's an issue with rhgb and
> starting X.  If I boot with an external display, the entire plymouth
> load sequence works fine, but then when X starts the external display
> goes blank and the internal display hangs on the plymouth screen.  On
> a related note, if I close the lid and turn off the LVDS output, gpm
> never blanks the external monitor.  I have to manually force dpms with
> xset.
> 

The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied 
my system mostly works now, but here's a summary about the problem I still have
with the lid detection:

- I boot up the laptop with lid closed (LVDS inactive) so there's only external
DVI display connected. Kernel boot messages show up on the external DVI display,
and GDM login prompt appears on the external DVI display. All fine so far.

- The actual problem: when X starts gnome panel etc show up on the internal LVDS
display, which I can't see at all since the lid is closed! So those should go 
to the
external DVI display only.. LVDS should be disconnected or inactive or 
something..

Any pointers appreciated where to look at in the source.. I can do some 
debugging.

-- Pasi

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jul 12, 2010 at 10:48:08AM -0400, Alex Deucher wrote:
> On Mon, Jul 12, 2010 at 7:53 AM, Pasi Kärkkäinen  wrote:
> > On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
> >> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez  
> >> wrote:
> >> > Jerome Glisse  writes:
> >> >
> >> >> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi Kärkkäinen wrote:
> >> >>> Hello,
> >> >>>
> >> >>> After fixing the dvi/hdmi detection problem I now have another problem
> >> >>> with the HP EliteBook 8530p, which has Radeon 3650HD adapter.
> >> >>>
> >> >>> Here's a summary of the environment:
> >> >>>
> >> >>>      - laptop connected to a docking station.
> >> >>>      - external display in use, connected with DVI to the dock.
> >> >>>      - laptop lid closed, so internal LVDS display is not used.
> >> >>>
> >> >>> Now, when I start the laptop, I can see the BIOS and grub on the 
> >> >>> external DVI display.
> >> >>> All fine so far. I select the Fedora 13 kernel, and Linux starts. I 
> >> >>> see the Fedora
> >> >>> graphical boot on the external DVI display, just like it should be. 
> >> >>> GDM login prompt
> >> >>> appears on the external DVI display, still everything fine.
> >> >>>
> >> >>> And then it goes wrong. After I login to X, the external display only 
> >> >>> shows the background
> >> >>> picture.. it turns out the desktop stuff has been started to the 
> >> >>> internal LVDS display,
> >> >>> which shouldn't be used at all since the laptop lid is closed!!
> >> >>>
> >> >>> When the laptop lid is closed, and external display is connected, I 
> >> >>> want to use only the external display..
> >> >>>
> >> >>> Any ideas how to troubleshoot this one?
> >>
> >> Does it work ok if you boot up without the external display connected
> >> and then connect and enable the secondary display after you've logged
> >> in?
> >>
> >
> > I just tried this.
> >
> > I boot up the laptop with lid open, so ONLY the internal LVDS is active
> > (DVI cable disconnected), and I get the GDM login prompt on the internal 
> > LVDS.
> >
> > Then I plug in the external DVI display, and the external display
> > gets automatically active when X starts. Gnome panel etc are on the 
> > internal LVDS,
> > external DVI display only has the background image and nothing else.
> >
> > So that works as expected. No problems there.
> >
> >>  I have a similar issue here;  I think it's an issue with rhgb and
> >> starting X.  If I boot with an external display, the entire plymouth
> >> load sequence works fine, but then when X starts the external display
> >> goes blank and the internal display hangs on the plymouth screen.  On
> >> a related note, if I close the lid and turn off the LVDS output, gpm
> >> never blanks the external monitor.  I have to manually force dpms with
> >> xset.
> >>
> >
> > The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied
> > my system mostly works now, but here's a summary about the problem I still 
> > have
> > with the lid detection:
> >
> > - I boot up the laptop with lid closed (LVDS inactive) so there's only 
> > external
> > DVI display connected. Kernel boot messages show up on the external DVI 
> > display,
> > and GDM login prompt appears on the external DVI display. All fine so far.
> >
> > - The actual problem: when X starts gnome panel etc show up on the internal 
> > LVDS
> > display, which I can't see at all since the lid is closed! So those should 
> > go to the
> > external DVI display only.. LVDS should be disconnected or inactive or 
> > something..
> >
> > Any pointers appreciated where to look at in the source.. I can do some 
> > debugging.
> 
> Your desktop session manager should check the lid status when it loads
> and attempt to do the right thing if there is an external monitor
> detected.
> 

Ok.
So you think it's not a bug in the lid detection? 

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 11:12:51AM -0400, Alex Deucher wrote:
> On Mon, Jun 21, 2010 at 10:53 AM, Francisco Jerez  
> wrote:
> > Jerome Glisse  writes:
> >
> >> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi Kärkkäinen wrote:
> >>> Hello,
> >>>
> >>> After fixing the dvi/hdmi detection problem I now have another problem
> >>> with the HP EliteBook 8530p, which has Radeon 3650HD adapter.
> >>>
> >>> Here's a summary of the environment:
> >>>
> >>>      - laptop connected to a docking station.
> >>>      - external display in use, connected with DVI to the dock.
> >>>      - laptop lid closed, so internal LVDS display is not used.
> >>>
> >>> Now, when I start the laptop, I can see the BIOS and grub on the external 
> >>> DVI display.
> >>> All fine so far. I select the Fedora 13 kernel, and Linux starts. I see 
> >>> the Fedora
> >>> graphical boot on the external DVI display, just like it should be. GDM 
> >>> login prompt
> >>> appears on the external DVI display, still everything fine.
> >>>
> >>> And then it goes wrong. After I login to X, the external display only 
> >>> shows the background
> >>> picture.. it turns out the desktop stuff has been started to the internal 
> >>> LVDS display,
> >>> which shouldn't be used at all since the laptop lid is closed!!
> >>>
> >>> When the laptop lid is closed, and external display is connected, I want 
> >>> to use only the external display..
> >>>
> >>> Any ideas how to troubleshoot this one?
> 
> Does it work ok if you boot up without the external display connected
> and then connect and enable the secondary display after you've logged
> in?
>

I just tried this.

I boot up the laptop with lid open, so ONLY the internal LVDS is active 
(DVI cable disconnected), and I get the GDM login prompt on the internal LVDS.

Then I plug in the external DVI display, and the external display
gets automatically active when X starts. Gnome panel etc are on the internal 
LVDS,
external DVI display only has the background image and nothing else.

So that works as expected. No problems there.

>  I have a similar issue here;  I think it's an issue with rhgb and
> starting X.  If I boot with an external display, the entire plymouth
> load sequence works fine, but then when X starts the external display
> goes blank and the internal display hangs on the plymouth screen.  On
> a related note, if I close the lid and turn off the LVDS output, gpm
> never blanks the external monitor.  I have to manually force dpms with
> xset.
> 

The other patch (0001-drm-radeon-kms-fix-shared-ddc-handling.patch) applied 
my system mostly works now, but here's a summary about the problem I still have
with the lid detection:

- I boot up the laptop with lid closed (LVDS inactive) so there's only external
DVI display connected. Kernel boot messages show up on the external DVI display,
and GDM login prompt appears on the external DVI display. All fine so far.

- The actual problem: when X starts gnome panel etc show up on the internal LVDS
display, which I can't see at all since the lid is closed! So those should go 
to the
external DVI display only.. LVDS should be disconnected or inactive or 
something..

Any pointers appreciated where to look at in the source.. I can do some 
debugging.

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Thu, Jul 01, 2010 at 10:35:34AM -0400, Alex Deucher wrote:
> On Thu, Jul 1, 2010 at 10:07 AM, Pasi K?rkk?inen  wrote:
> > On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi K?rkk?inen wrote:
> >> > >>
> >> > >> I am not sure your patch is right, my guess is that devices field of
> >> > >> radeon connector structure btw the HDMI & DVI connector are different
> >> > >> and thus that drm_detect_hdmi_monitor is not call. I expect it's 
> >> > >> normal
> >> > >> for the device field to be different (my understanding being that HDMI
> >> > >> will have one more bit set than the DVI connector). Bottom line is
> >> > >> i think we want to discard non hdmi connector just in case we face
> >> > >> shared connector.
> >> > >>
> >> > >> Alex would have to comment on the device field test, maybe your 
> >> > >> atombios
> >> > >> is broken. Does it works if instead of removing
> >> > >> if (connector == list_connector)
> >> > >> ? ? ? ?continue;
> >> > >> You remove :
> >> > >> if (radeon_connector->devices == list_radeon_connector->devices)
> >> > >>
> >> > >> Also can you print the radeon_connector->devices of all your connector
> >> > >> so we can compare them.
> >> > >
> >> > > The code was for systems with shared ddc lines and shared encoders,
> >> > > but it looks like your system may have a shared ddc line and (sort of)
> >> > > non-shared encoders. ?I suspect the DVI port is using UNIPHY A or A+B
> >> > > (for dual link) and HDMI is using UNIPHY link B. ?It's probably
> >> > > actually using router objects (gpio toggle to switch gpio routing
> >> > > between physical ports), however support for that is not implemented
> >> > > yet which is why we have the current code. ?Can you send me a copy of
> >> > > your vbios so I can verify?
> >> > >
> >> > > To access your vbios (as root):
> >> > > cd /sys/bus/pci/device/
> >> > > echo 1 > rom
> >> > > cat rom > /tmp/vbios.rom
> >> > > echo 0 > rom
> >> >
> >> > Does the attached patch fix the issue?
> >> >
> >>
> >> Thanks for the patch. I'll try it when I'm back where the dock is.. will 
> >> take a couple of days.
> >>
> >
> > Sorry it took a while.. I tried your patch now.
> > It seems to fix the problem!
> >
> > When you send it upstream please also CC it for 2.6.33/2.6.34 stable 
> > branches?
> > Just hoping to get the fix into Fedora 13..
> >
> 
> I've sent the patch to Dave and cc'ed stable.
> 

Great, thanks!

-- Pasi

> Alex
> 
> > -- Pasi
> >
> >>
> >>
> >> > From 557b452536c9390105539a264d342d963d71b087 Mon Sep 17 00:00:00 2001
> >> > From: Alex Deucher 
> >> > Date: Mon, 21 Jun 2010 12:07:52 -0400
> >> > Subject: [PATCH] drm/radeon/kms: fix shared ddc handling
> >> > MIME-Version: 1.0
> >> > Content-Type: text/plain; charset=UTF-8
> >> > Content-Transfer-Encoding: 8bit
> >> >
> >> > Connectors with a shared ddc line can be connected to different
> >> > encoders.
> >> >
> >> > Reported by Pasi K?rkk?inen  on dri-devel
> >> >
> >> > Signed-off-by: Alex Deucher 
> >> > ---
> >> > ?drivers/gpu/drm/radeon/radeon_connectors.c | ? ?4 +++-
> >> > ?1 files changed, 3 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> >> > b/drivers/gpu/drm/radeon/radeon_connectors.c
> >> > index 0c7ccc6..f58f8bd 100644
> >> > --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> >> > +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> >> > @@ -785,7 +785,9 @@ static enum drm_connector_status 
> >> > radeon_dvi_detect(struct drm_connector *connect
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (connector == list_connector)
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? continue;
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? list_radeon_connector = 
> >> > to_radeon_connector(list_connector);
> >> > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (radeon_connector->devices == 
> >> > list_radeon_connector->devices) {
> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if 
> >> > (list_radeon_connector->shared_ddc &&
> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> >> > (list_radeon_connector->ddc_bus->rec.i2c_id ==
> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> >> > ?radeon_connector->ddc_bus->rec.i2c_id)) {
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if 
> >> > (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if 
> >> > (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> >> > kfree(radeon_connector->edid);
> >> > --
> >> > 1.7.0.1
> >> >
> >>
> >

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi K?rkk?inen wrote:
> > >>
> > >> I am not sure your patch is right, my guess is that devices field of
> > >> radeon connector structure btw the HDMI & DVI connector are different
> > >> and thus that drm_detect_hdmi_monitor is not call. I expect it's normal
> > >> for the device field to be different (my understanding being that HDMI
> > >> will have one more bit set than the DVI connector). Bottom line is
> > >> i think we want to discard non hdmi connector just in case we face
> > >> shared connector.
> > >>
> > >> Alex would have to comment on the device field test, maybe your atombios
> > >> is broken. Does it works if instead of removing
> > >> if (connector == list_connector)
> > >> ? ? ? ?continue;
> > >> You remove :
> > >> if (radeon_connector->devices == list_radeon_connector->devices)
> > >>
> > >> Also can you print the radeon_connector->devices of all your connector
> > >> so we can compare them.
> > >
> > > The code was for systems with shared ddc lines and shared encoders,
> > > but it looks like your system may have a shared ddc line and (sort of)
> > > non-shared encoders. ?I suspect the DVI port is using UNIPHY A or A+B
> > > (for dual link) and HDMI is using UNIPHY link B. ?It's probably
> > > actually using router objects (gpio toggle to switch gpio routing
> > > between physical ports), however support for that is not implemented
> > > yet which is why we have the current code. ?Can you send me a copy of
> > > your vbios so I can verify?
> > >
> > > To access your vbios (as root):
> > > cd /sys/bus/pci/device/
> > > echo 1 > rom
> > > cat rom > /tmp/vbios.rom
> > > echo 0 > rom
> > 
> > Does the attached patch fix the issue?
> > 
> 
> Thanks for the patch. I'll try it when I'm back where the dock is.. will take 
> a couple of days.
> 

Sorry it took a while.. I tried your patch now. 
It seems to fix the problem! 

When you send it upstream please also CC it for 2.6.33/2.6.34 stable branches?
Just hoping to get the fix into Fedora 13..

-- Pasi

> 
> 
> > From 557b452536c9390105539a264d342d963d71b087 Mon Sep 17 00:00:00 2001
> > From: Alex Deucher 
> > Date: Mon, 21 Jun 2010 12:07:52 -0400
> > Subject: [PATCH] drm/radeon/kms: fix shared ddc handling
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> > 
> > Connectors with a shared ddc line can be connected to different
> > encoders.
> > 
> > Reported by Pasi K?rkk?inen  on dri-devel
> > 
> > Signed-off-by: Alex Deucher 
> > ---
> >  drivers/gpu/drm/radeon/radeon_connectors.c |4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> > b/drivers/gpu/drm/radeon/radeon_connectors.c
> > index 0c7ccc6..f58f8bd 100644
> > --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> > +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> > @@ -785,7 +785,9 @@ static enum drm_connector_status 
> > radeon_dvi_detect(struct drm_connector *connect
> > if (connector == list_connector)
> > continue;
> > list_radeon_connector = 
> > to_radeon_connector(list_connector);
> > -   if (radeon_connector->devices == 
> > list_radeon_connector->devices) {
> > +   if (list_radeon_connector->shared_ddc &&
> > +   
> > (list_radeon_connector->ddc_bus->rec.i2c_id ==
> > +
> > radeon_connector->ddc_bus->rec.i2c_id)) {
> > if 
> > (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> > if 
> > (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> > 
> > kfree(radeon_connector->edid);
> > -- 
> > 1.7.0.1
> > 
> 

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 09:17:14PM +0300, Pasi K?rkk?inen wrote:
> > >
> > > I am not sure your patch is right, my guess is that devices field of
> > > radeon connector structure btw the HDMI & DVI connector are different
> > > and thus that drm_detect_hdmi_monitor is not call. I expect it's normal
> > > for the device field to be different (my understanding being that HDMI
> > > will have one more bit set than the DVI connector). Bottom line is
> > > i think we want to discard non hdmi connector just in case we face
> > > shared connector.
> > >
> > > Alex would have to comment on the device field test, maybe your atombios
> > > is broken. Does it works if instead of removing
> > > if (connector == list_connector)
> > > ? ? ? ?continue;
> > > You remove :
> > > if (radeon_connector->devices == list_radeon_connector->devices)
> > >
> > > Also can you print the radeon_connector->devices of all your connector
> > > so we can compare them.
> > 
> > The code was for systems with shared ddc lines and shared encoders,
> > but it looks like your system may have a shared ddc line and (sort of)
> > non-shared encoders.  I suspect the DVI port is using UNIPHY A or A+B
> > (for dual link) and HDMI is using UNIPHY link B.  It's probably
> > actually using router objects (gpio toggle to switch gpio routing
> > between physical ports), however support for that is not implemented
> > yet which is why we have the current code.  Can you send me a copy of
> > your vbios so I can verify?
> > 
> > To access your vbios (as root):
> > cd /sys/bus/pci/device/
> > echo 1 > rom
> > cat rom > /tmp/vbios.rom
> > echo 0 > rom
> > 
> 
> 
> Here you are:
> http://pasik.reaktio.net/fedora/bz593429/vbios-hp-elitebook-8530p-ati-radeon-hd3650.rom
> 

Did you have a chance to take a look at that rom? 

dmesg says this btw:
ATOM BIOS: HP_Wistron_Vox_M86M

-- Pasi

> 
> # lspci -vv
> 
> 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 
> 3650 (prog-if 00 [VGA controller])
> Subsystem: Hewlett-Packard Company Device 30e7
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 33
> Region 0: Memory at c000 (32-bit, prefetchable) [size=256M]
> Region 1: I/O ports at 7000 [size=256]
> Region 2: Memory at d830 (32-bit, non-prefetchable) [size=64K]
> Expansion ROM at d832 [disabled] [size=128K]
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, 
> L1 unlimited
> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
> Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
> TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, 
> Latency L0 <64ns, L1 <1us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- 
> CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Not Supported, TimeoutDis-
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>   LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
> SpeedDis-, Selectable De-emphasis: -6dB
>  Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>  Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -3.5dB
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: fee0200c  Data: 41d1
> Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 
> Len=010 
> Kernel driver in use: radeon
> Kernel modules: radeon
> 
> 01:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 
> Series]
> Subsystem: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 
> Series]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0, Cache Line Size

Re: [RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Thu, Jul 01, 2010 at 10:35:34AM -0400, Alex Deucher wrote:
> On Thu, Jul 1, 2010 at 10:07 AM, Pasi Kärkkäinen  wrote:
> > On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi Kärkkäinen wrote:
> >> > >>
> >> > >> I am not sure your patch is right, my guess is that devices field of
> >> > >> radeon connector structure btw the HDMI & DVI connector are different
> >> > >> and thus that drm_detect_hdmi_monitor is not call. I expect it's 
> >> > >> normal
> >> > >> for the device field to be different (my understanding being that HDMI
> >> > >> will have one more bit set than the DVI connector). Bottom line is
> >> > >> i think we want to discard non hdmi connector just in case we face
> >> > >> shared connector.
> >> > >>
> >> > >> Alex would have to comment on the device field test, maybe your 
> >> > >> atombios
> >> > >> is broken. Does it works if instead of removing
> >> > >> if (connector == list_connector)
> >> > >>        continue;
> >> > >> You remove :
> >> > >> if (radeon_connector->devices == list_radeon_connector->devices)
> >> > >>
> >> > >> Also can you print the radeon_connector->devices of all your connector
> >> > >> so we can compare them.
> >> > >
> >> > > The code was for systems with shared ddc lines and shared encoders,
> >> > > but it looks like your system may have a shared ddc line and (sort of)
> >> > > non-shared encoders.  I suspect the DVI port is using UNIPHY A or A+B
> >> > > (for dual link) and HDMI is using UNIPHY link B.  It's probably
> >> > > actually using router objects (gpio toggle to switch gpio routing
> >> > > between physical ports), however support for that is not implemented
> >> > > yet which is why we have the current code.  Can you send me a copy of
> >> > > your vbios so I can verify?
> >> > >
> >> > > To access your vbios (as root):
> >> > > cd /sys/bus/pci/device/
> >> > > echo 1 > rom
> >> > > cat rom > /tmp/vbios.rom
> >> > > echo 0 > rom
> >> >
> >> > Does the attached patch fix the issue?
> >> >
> >>
> >> Thanks for the patch. I'll try it when I'm back where the dock is.. will 
> >> take a couple of days.
> >>
> >
> > Sorry it took a while.. I tried your patch now.
> > It seems to fix the problem!
> >
> > When you send it upstream please also CC it for 2.6.33/2.6.34 stable 
> > branches?
> > Just hoping to get the fix into Fedora 13..
> >
> 
> I've sent the patch to Dave and cc'ed stable.
> 

Great, thanks!

-- Pasi

> Alex
> 
> > -- Pasi
> >
> >>
> >>
> >> > From 557b452536c9390105539a264d342d963d71b087 Mon Sep 17 00:00:00 2001
> >> > From: Alex Deucher 
> >> > Date: Mon, 21 Jun 2010 12:07:52 -0400
> >> > Subject: [PATCH] drm/radeon/kms: fix shared ddc handling
> >> > MIME-Version: 1.0
> >> > Content-Type: text/plain; charset=UTF-8
> >> > Content-Transfer-Encoding: 8bit
> >> >
> >> > Connectors with a shared ddc line can be connected to different
> >> > encoders.
> >> >
> >> > Reported by Pasi Kärkkäinen  on dri-devel
> >> >
> >> > Signed-off-by: Alex Deucher 
> >> > ---
> >> >  drivers/gpu/drm/radeon/radeon_connectors.c |    4 +++-
> >> >  1 files changed, 3 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> >> > b/drivers/gpu/drm/radeon/radeon_connectors.c
> >> > index 0c7ccc6..f58f8bd 100644
> >> > --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> >> > +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> >> > @@ -785,7 +785,9 @@ static enum drm_connector_status 
> >> > radeon_dvi_detect(struct drm_connector *connect
> >> >                                     if (connector == list_connector)
> >> >                                             continue;
> >> >                                     list_radeon_connector = 
> >> > to_radeon_connector(list_connector);
> >> > -                                   if (radeon_connector->devices == 
> >> > list_radeon_connector->devices) {
> >> > +                                   if 
> >> > (list_radeon_connector->shared_ddc &&
> >> > +                                       
> >> > (list_radeon_connector->ddc_bus->rec.i2c_id ==
> >> > +                                        
> >> > radeon_connector->ddc_bus->rec.i2c_id)) {
> >> >                                             if 
> >> > (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> >> >                                                     if 
> >> > (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> >> >                                                             
> >> > kfree(radeon_connector->edid);
> >> > --
> >> > 1.7.0.1
> >> >
> >>
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 09:18:01PM +0300, Pasi Kärkkäinen wrote:
> > >>
> > >> I am not sure your patch is right, my guess is that devices field of
> > >> radeon connector structure btw the HDMI & DVI connector are different
> > >> and thus that drm_detect_hdmi_monitor is not call. I expect it's normal
> > >> for the device field to be different (my understanding being that HDMI
> > >> will have one more bit set than the DVI connector). Bottom line is
> > >> i think we want to discard non hdmi connector just in case we face
> > >> shared connector.
> > >>
> > >> Alex would have to comment on the device field test, maybe your atombios
> > >> is broken. Does it works if instead of removing
> > >> if (connector == list_connector)
> > >>        continue;
> > >> You remove :
> > >> if (radeon_connector->devices == list_radeon_connector->devices)
> > >>
> > >> Also can you print the radeon_connector->devices of all your connector
> > >> so we can compare them.
> > >
> > > The code was for systems with shared ddc lines and shared encoders,
> > > but it looks like your system may have a shared ddc line and (sort of)
> > > non-shared encoders.  I suspect the DVI port is using UNIPHY A or A+B
> > > (for dual link) and HDMI is using UNIPHY link B.  It's probably
> > > actually using router objects (gpio toggle to switch gpio routing
> > > between physical ports), however support for that is not implemented
> > > yet which is why we have the current code.  Can you send me a copy of
> > > your vbios so I can verify?
> > >
> > > To access your vbios (as root):
> > > cd /sys/bus/pci/device/
> > > echo 1 > rom
> > > cat rom > /tmp/vbios.rom
> > > echo 0 > rom
> > 
> > Does the attached patch fix the issue?
> > 
> 
> Thanks for the patch. I'll try it when I'm back where the dock is.. will take 
> a couple of days.
> 

Sorry it took a while.. I tried your patch now. 
It seems to fix the problem! 

When you send it upstream please also CC it for 2.6.33/2.6.34 stable branches?
Just hoping to get the fix into Fedora 13..

-- Pasi

> 
> 
> > From 557b452536c9390105539a264d342d963d71b087 Mon Sep 17 00:00:00 2001
> > From: Alex Deucher 
> > Date: Mon, 21 Jun 2010 12:07:52 -0400
> > Subject: [PATCH] drm/radeon/kms: fix shared ddc handling
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> > 
> > Connectors with a shared ddc line can be connected to different
> > encoders.
> > 
> > Reported by Pasi Kärkkäinen  on dri-devel
> > 
> > Signed-off-by: Alex Deucher 
> > ---
> >  drivers/gpu/drm/radeon/radeon_connectors.c |4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> > b/drivers/gpu/drm/radeon/radeon_connectors.c
> > index 0c7ccc6..f58f8bd 100644
> > --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> > +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> > @@ -785,7 +785,9 @@ static enum drm_connector_status 
> > radeon_dvi_detect(struct drm_connector *connect
> > if (connector == list_connector)
> > continue;
> > list_radeon_connector = 
> > to_radeon_connector(list_connector);
> > -   if (radeon_connector->devices == 
> > list_radeon_connector->devices) {
> > +   if (list_radeon_connector->shared_ddc &&
> > +   
> > (list_radeon_connector->ddc_bus->rec.i2c_id ==
> > +
> > radeon_connector->ddc_bus->rec.i2c_id)) {
> > if 
> > (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> > if 
> > (connector->connector_type == DRM_MODE_CONNECTOR_DVID) {
> > 
> > kfree(radeon_connector->edid);
> > -- 
> > 1.7.0.1
> > 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 09:17:14PM +0300, Pasi Kärkkäinen wrote:
> > >
> > > I am not sure your patch is right, my guess is that devices field of
> > > radeon connector structure btw the HDMI & DVI connector are different
> > > and thus that drm_detect_hdmi_monitor is not call. I expect it's normal
> > > for the device field to be different (my understanding being that HDMI
> > > will have one more bit set than the DVI connector). Bottom line is
> > > i think we want to discard non hdmi connector just in case we face
> > > shared connector.
> > >
> > > Alex would have to comment on the device field test, maybe your atombios
> > > is broken. Does it works if instead of removing
> > > if (connector == list_connector)
> > >        continue;
> > > You remove :
> > > if (radeon_connector->devices == list_radeon_connector->devices)
> > >
> > > Also can you print the radeon_connector->devices of all your connector
> > > so we can compare them.
> > 
> > The code was for systems with shared ddc lines and shared encoders,
> > but it looks like your system may have a shared ddc line and (sort of)
> > non-shared encoders.  I suspect the DVI port is using UNIPHY A or A+B
> > (for dual link) and HDMI is using UNIPHY link B.  It's probably
> > actually using router objects (gpio toggle to switch gpio routing
> > between physical ports), however support for that is not implemented
> > yet which is why we have the current code.  Can you send me a copy of
> > your vbios so I can verify?
> > 
> > To access your vbios (as root):
> > cd /sys/bus/pci/device/
> > echo 1 > rom
> > cat rom > /tmp/vbios.rom
> > echo 0 > rom
> > 
> 
> 
> Here you are:
> http://pasik.reaktio.net/fedora/bz593429/vbios-hp-elitebook-8530p-ati-radeon-hd3650.rom
> 

Did you have a chance to take a look at that rom? 

dmesg says this btw:
ATOM BIOS: HP_Wistron_Vox_M86M

-- Pasi

> 
> # lspci -vv
> 
> 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 
> 3650 (prog-if 00 [VGA controller])
> Subsystem: Hewlett-Packard Company Device 30e7
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 33
> Region 0: Memory at c000 (32-bit, prefetchable) [size=256M]
> Region 1: I/O ports at 7000 [size=256]
> Region 2: Memory at d830 (32-bit, non-prefetchable) [size=64K]
> Expansion ROM at d832 [disabled] [size=128K]
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, 
> L1 unlimited
> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
> Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
> TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, 
> Latency L0 <64ns, L1 <1us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- 
> CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Not Supported, TimeoutDis-
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>   LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
> SpeedDis-, Selectable De-emphasis: -6dB
>  Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>  Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -3.5dB
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: fee0200c  Data: 41d1
> Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 
> Len=010 
> Kerne

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 12:11:49PM -0400, Alex Deucher wrote:
> On Mon, Jun 21, 2010 at 11:03 AM, Alex Deucher  
> wrote:
> > On Mon, Jun 21, 2010 at 8:45 AM, Jerome Glisse  
> > wrote:
> >> On Mon, Jun 21, 2010 at 12:31:22PM +0300, Pasi K?rkk?inen wrote:
> >>> On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi K?rkk?inen wrote:
> >>> > On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi K?rkk?inen wrote:
> >>> > > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi K?rkk?inen wrote:
> >>> > > > > > > >> >
> >>> > > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I 
> >>> > > > > > > >> > don't have anything connected
> >>> > > > > > > >> > to the HDMI connector on the laptop. There's no HDMI 
> >>> > > > > > > >> > connector on the dock, it's only in the laptop.
> >>> > > > > > > >>
> >>> > > > > > > >> Indeed that is the problem. ?On your system the HDMI and 
> >>> > > > > > > >> DVI ports
> >>> > > > > > > >> share the same encoder and DDC line so they will both come 
> >>> > > > > > > >> up as
> >>> > > > > > > >> connected since the line is shared. ?The driver used to 
> >>> > > > > > > >> check the edid
> >>> > > > > > > >> when the lines where shared and select HDMI or DVI based 
> >>> > > > > > > >> on the EDID,
> >>> > > > > > > >> but perhaps that got broken at some point.
> >>> > > > > > > >>
> >>> > > > > > > >
> >>> > > > > > > > Makes sense. Does some kernel option/parameter affect that?
> >>> > > > > > >
> >>> > > > > > > No. ?I'll check the code and see if I can figure out what's 
> >>> > > > > > > going on.
> >>> > > > > > >
> >>> > > > > >
> >>> > > > > > Ok, thanks!
> >>> > > > > >
> >>> > > > >
> >>> > > > > Hello,
> >>> > > > >
> >>> > > > > I'll be near the dock tomorrow.. So if you have a chance of 
> >>> > > > > looking at this, and want me to test something,
> >>> > > > > I could do it on thursday/friday.
> >>> > > > >
> >>> > > >
> >>> > > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) 
> >>> > > > and the latest
> >>> > > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> >>> > > > behaviour was the same.
> >>> > > >
> >>> > > > Connecting display to the DVI connector makes the HDMI connector 
> >>> > > > also show the same display,
> >>> > > > breaking things..
> >>> > > >
> >>> > >
> >>> > > Here's a new log with drm.debug=4.. that's the biggest debug level 
> >>> > > that still allows me to grab
> >>> > > the whole dmesg log before it's overwritten by huge amount of debug 
> >>> > > messages.
> >>> > >
> >>> > > Full dmesg log:
> >>> > > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> >>> > >
> >>> >
> >>> > Ok.. I did some debugging, and figured out how to make it work. Patch 
> >>> > attached.
> >>> > I'm not sure if this is the correct method.. someone familiar with the 
> >>> > code should review it.
> >>> >
> >>> >
> >>> > Some debugging information for my system (HP EliteBook 8530p):
> >>> >
> >>> > >
> >>> > > [drm] Radeon Display Connectors
> >>> > > [drm] Connector 0:
> >>> > > [drm] ? VGA
> >>> > > [drm] ? DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> >>> > > [drm] ? Encoders:
> >>> > > [drm] ? ? CRT1: INTERNAL_KLDSCP_DAC1
> >>> >
> >>> > connector->devices for VGA is: 1
> >>> >
> >>> > > [drm] Connector 1:
> >>> > > [drm] ? LVDS
> >>> > > [drm] ? Encoders:
> >>> > > [drm] ? ? LCD1: INTERNAL_KLDSCP_LVTMA
> >>> >
> >>> > connector->devices for LVDS is: 2
> >>> >
> >>> > > [drm] Connector 2:
> >>> > > [drm] ? DVI-D
> >>> > > [drm] ? HPD1
> >>> > > [drm] ? DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> >>> > > [drm] ? Encoders:
> >>> > > [drm] ? ? DFP1: INTERNAL_UNIPHY
> >>> >
> >>> > connector->devices for DVI-D is: 8
> >>> >
> >>> > > [drm] Connector 3:
> >>> > > [drm] ? HDMI-A
> >>> > > [drm] ? HPD2
> >>> > > [drm] ? DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> >>> > > [drm] ? Encoders:
> >>> > > [drm] ? ? DFP2: INTERNAL_UNIPHY
> >>> >
> >>> > connector->devices for HDMI-A is: 128
> >>> >
> >>> >
> >>> >
> >>> > The code in radeon_connectors.c in radeon_dvi_detect():
> >>> >
> >>> > ? ? /* multiple connectors on the same encoder with the same ddc line
> >>> > ? ? ?* This tends to be HDMI and DVI on the same encoder with the
> >>> > ? ? ?* same ddc line. ?If the edid says HDMI, consider the HDMI port
> >>> > ? ? ?* connected and the DVI port disconnected. ?If the edid doesn't
> >>> > ? ? ?* say HDMI, vice versa.
> >>> > ? ? ?*/
> >>> > ? ? if (radeon_connector->shared_ddc && (ret == 
> >>> > connector_status_connected)) {
> >>> > ? ? ? ? ? ? struct drm_device *dev = connector->dev;
> >>> > ? ? ? ? ? ? struct drm_connector *list_connector;
> >>> > ? ? ? ? ? ? struct radeon_connector *list_radeon_connector;
> >>> > ? ? ? ? ? ? list_for_each_entry(list_connector, 
> >>> > &dev->mode_config.connector_list, head) {
> >>> > ? ? ? ? ? ? ? ? ? ? if (connector == list_connector)
> >>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? cont

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 11:03:08AM -0400, Alex Deucher wrote:
> On Mon, Jun 21, 2010 at 8:45 AM, Jerome Glisse  
> wrote:
> > On Mon, Jun 21, 2010 at 12:31:22PM +0300, Pasi K?rkk?inen wrote:
> >> On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi K?rkk?inen wrote:
> >> > On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi K?rkk?inen wrote:
> >> > > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi K?rkk?inen wrote:
> >> > > > > > > >> >
> >> > > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I 
> >> > > > > > > >> > don't have anything connected
> >> > > > > > > >> > to the HDMI connector on the laptop. There's no HDMI 
> >> > > > > > > >> > connector on the dock, it's only in the laptop.
> >> > > > > > > >>
> >> > > > > > > >> Indeed that is the problem. ?On your system the HDMI and 
> >> > > > > > > >> DVI ports
> >> > > > > > > >> share the same encoder and DDC line so they will both come 
> >> > > > > > > >> up as
> >> > > > > > > >> connected since the line is shared. ?The driver used to 
> >> > > > > > > >> check the edid
> >> > > > > > > >> when the lines where shared and select HDMI or DVI based on 
> >> > > > > > > >> the EDID,
> >> > > > > > > >> but perhaps that got broken at some point.
> >> > > > > > > >>
> >> > > > > > > >
> >> > > > > > > > Makes sense. Does some kernel option/parameter affect that?
> >> > > > > > >
> >> > > > > > > No. ?I'll check the code and see if I can figure out what's 
> >> > > > > > > going on.
> >> > > > > > >
> >> > > > > >
> >> > > > > > Ok, thanks!
> >> > > > > >
> >> > > > >
> >> > > > > Hello,
> >> > > > >
> >> > > > > I'll be near the dock tomorrow.. So if you have a chance of 
> >> > > > > looking at this, and want me to test something,
> >> > > > > I could do it on thursday/friday.
> >> > > > >
> >> > > >
> >> > > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) 
> >> > > > and the latest
> >> > > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> >> > > > behaviour was the same.
> >> > > >
> >> > > > Connecting display to the DVI connector makes the HDMI connector 
> >> > > > also show the same display,
> >> > > > breaking things..
> >> > > >
> >> > >
> >> > > Here's a new log with drm.debug=4.. that's the biggest debug level 
> >> > > that still allows me to grab
> >> > > the whole dmesg log before it's overwritten by huge amount of debug 
> >> > > messages.
> >> > >
> >> > > Full dmesg log:
> >> > > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> >> > >
> >> >
> >> > Ok.. I did some debugging, and figured out how to make it work. Patch 
> >> > attached.
> >> > I'm not sure if this is the correct method.. someone familiar with the 
> >> > code should review it.
> >> >
> >> >
> >> > Some debugging information for my system (HP EliteBook 8530p):
> >> >
> >> > >
> >> > > [drm] Radeon Display Connectors
> >> > > [drm] Connector 0:
> >> > > [drm] ? VGA
> >> > > [drm] ? DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> >> > > [drm] ? Encoders:
> >> > > [drm] ? ? CRT1: INTERNAL_KLDSCP_DAC1
> >> >
> >> > connector->devices for VGA is: 1
> >> >
> >> > > [drm] Connector 1:
> >> > > [drm] ? LVDS
> >> > > [drm] ? Encoders:
> >> > > [drm] ? ? LCD1: INTERNAL_KLDSCP_LVTMA
> >> >
> >> > connector->devices for LVDS is: 2
> >> >
> >> > > [drm] Connector 2:
> >> > > [drm] ? DVI-D
> >> > > [drm] ? HPD1
> >> > > [drm] ? DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> >> > > [drm] ? Encoders:
> >> > > [drm] ? ? DFP1: INTERNAL_UNIPHY
> >> >
> >> > connector->devices for DVI-D is: 8
> >> >
> >> > > [drm] Connector 3:
> >> > > [drm] ? HDMI-A
> >> > > [drm] ? HPD2
> >> > > [drm] ? DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> >> > > [drm] ? Encoders:
> >> > > [drm] ? ? DFP2: INTERNAL_UNIPHY
> >> >
> >> > connector->devices for HDMI-A is: 128
> >> >
> >> >
> >> >
> >> > The code in radeon_connectors.c in radeon_dvi_detect():
> >> >
> >> > ? ? /* multiple connectors on the same encoder with the same ddc line
> >> > ? ? ?* This tends to be HDMI and DVI on the same encoder with the
> >> > ? ? ?* same ddc line. ?If the edid says HDMI, consider the HDMI port
> >> > ? ? ?* connected and the DVI port disconnected. ?If the edid doesn't
> >> > ? ? ?* say HDMI, vice versa.
> >> > ? ? ?*/
> >> > ? ? if (radeon_connector->shared_ddc && (ret == 
> >> > connector_status_connected)) {
> >> > ? ? ? ? ? ? struct drm_device *dev = connector->dev;
> >> > ? ? ? ? ? ? struct drm_connector *list_connector;
> >> > ? ? ? ? ? ? struct radeon_connector *list_radeon_connector;
> >> > ? ? ? ? ? ? list_for_each_entry(list_connector, 
> >> > &dev->mode_config.connector_list, head) {
> >> > ? ? ? ? ? ? ? ? ? ? if (connector == list_connector)
> >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? continue;
> >> > ? ? ? ? ? ? ? ? ? ? list_radeon_connector = 
> >> > to_radeon_connector(list_connector);
> >> > ? ? ? ? ? ? ? ? ? ? if (radeon_connector->devices == 
> >> > list_radeon_

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 02:51:59PM +0200, Jerome Glisse wrote:
> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi K?rkk?inen wrote:
> > Hello,
> > 
> > After fixing the dvi/hdmi detection problem I now have another problem
> > with the HP EliteBook 8530p, which has Radeon 3650HD adapter.
> > 
> > Here's a summary of the environment:
> > 
> > - laptop connected to a docking station.
> > - external display in use, connected with DVI to the dock.
> > - laptop lid closed, so internal LVDS display is not used.
> > 
> > Now, when I start the laptop, I can see the BIOS and grub on the external 
> > DVI display.
> > All fine so far. I select the Fedora 13 kernel, and Linux starts. I see the 
> > Fedora
> > graphical boot on the external DVI display, just like it should be. GDM 
> > login prompt
> > appears on the external DVI display, still everything fine.
> > 
> > And then it goes wrong. After I login to X, the external display only shows 
> > the background
> > picture.. it turns out the desktop stuff has been started to the internal 
> > LVDS display,
> > which shouldn't be used at all since the laptop lid is closed!! 
> > 
> > When the laptop lid is closed, and external display is connected, I want to 
> > use only the external display..
> > 
> > Any ideas how to troubleshoot this one? 
> > 
> > -- Pasi
> > 
> 
> It's better to open bug when you face issue rather than mail, as it's
> harder to track information in mail thread than in a bug. Your issue
> is not easily fixed because there is many laptop with broken acpi which
> report wrong lid status (some of them always report lid closed what ever
> is the lid status, other always report lid open, ... i am not expert on
> how broken this is but from what i have been told i should rather consider
> drinking than trying to look into it and then go to the drinking step).
> 

Hey, I'm from Finland, so drinking and debugging is not a problem ;)

> Bottom line is that lid detection is unreliable thus so far we ignore
> it silently. I think the plan is to monitor lid status change and if
> we detect change from either open to close or close to open then we
> can start assuming that acpi lid status is reliable and act accordingly.
> 

I hate to play the "windows card" but the lid detection seems to work in 
windows.. 
so there's a way to make it work :)

-- Pasi

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 02:45:44PM +0200, Jerome Glisse wrote:
> On Mon, Jun 21, 2010 at 12:31:22PM +0300, Pasi K?rkk?inen wrote:
> > On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi K?rkk?inen wrote:
> > > On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi K?rkk?inen wrote:
> > > > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi K?rkk?inen wrote:
> > > > > > > > >> >
> > > > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I 
> > > > > > > > >> > don't have anything connected
> > > > > > > > >> > to the HDMI connector on the laptop. There's no HDMI 
> > > > > > > > >> > connector on the dock, it's only in the laptop.
> > > > > > > > >>
> > > > > > > > >> Indeed that is the problem. ?On your system the HDMI and DVI 
> > > > > > > > >> ports
> > > > > > > > >> share the same encoder and DDC line so they will both come 
> > > > > > > > >> up as
> > > > > > > > >> connected since the line is shared. ?The driver used to 
> > > > > > > > >> check the edid
> > > > > > > > >> when the lines where shared and select HDMI or DVI based on 
> > > > > > > > >> the EDID,
> > > > > > > > >> but perhaps that got broken at some point.
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > > Makes sense. Does some kernel option/parameter affect that?
> > > > > > > > 
> > > > > > > > No.  I'll check the code and see if I can figure out what's 
> > > > > > > > going on.
> > > > > > > > 
> > > > > > > 
> > > > > > > Ok, thanks!
> > > > > > > 
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I'll be near the dock tomorrow.. So if you have a chance of looking 
> > > > > > at this, and want me to test something,
> > > > > > I could do it on thursday/friday.
> > > > > > 
> > > > > 
> > > > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) 
> > > > > and the latest 
> > > > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> > > > > behaviour was the same.
> > > > > 
> > > > > Connecting display to the DVI connector makes the HDMI connector also 
> > > > > show the same display, 
> > > > > breaking things..
> > > > > 
> > > > 
> > > > Here's a new log with drm.debug=4.. that's the biggest debug level that 
> > > > still allows me to grab
> > > > the whole dmesg log before it's overwritten by huge amount of debug 
> > > > messages.
> > > > 
> > > > Full dmesg log:
> > > > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> > > > 
> > > 
> > > Ok.. I did some debugging, and figured out how to make it work. Patch 
> > > attached.
> > > I'm not sure if this is the correct method.. someone familiar with the 
> > > code should review it.
> > > 
> > > 
> > > Some debugging information for my system (HP EliteBook 8530p):
> > > 
> > > > 
> > > > [drm] Radeon Display Connectors
> > > > [drm] Connector 0:
> > > > [drm]   VGA
> > > > [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> > > > [drm]   Encoders:
> > > > [drm] CRT1: INTERNAL_KLDSCP_DAC1
> > > 
> > > connector->devices for VGA is: 1
> > > 
> > > > [drm] Connector 1:
> > > > [drm]   LVDS
> > > > [drm]   Encoders:
> > > > [drm] LCD1: INTERNAL_KLDSCP_LVTMA
> > > 
> > > connector->devices for LVDS is: 2
> > > 
> > > > [drm] Connector 2:
> > > > [drm]   DVI-D
> > > > [drm]   HPD1
> > > > [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> > > > [drm]   Encoders:
> > > > [drm] DFP1: INTERNAL_UNIPHY
> > > 
> > > connector->devices for DVI-D is: 8
> > > 
> > > > [drm] Connector 3:
> > > > [drm]   HDMI-A
> > > > [drm]   HPD2
> > > > [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> > > > [drm]   Encoders:
> > > > [drm] DFP2: INTERNAL_UNIPHY
> > > 
> > > connector->devices for HDMI-A is: 128
> > > 
> > > 
> > > 
> > > The code in radeon_connectors.c in radeon_dvi_detect():
> > > 
> > >   /* multiple connectors on the same encoder with the same ddc line
> > >* This tends to be HDMI and DVI on the same encoder with the
> > >* same ddc line.  If the edid says HDMI, consider the HDMI port
> > >* connected and the DVI port disconnected.  If the edid doesn't
> > >* say HDMI, vice versa.
> > >*/
> > >   if (radeon_connector->shared_ddc && (ret == 
> > > connector_status_connected)) {
> > >   struct drm_device *dev = connector->dev;
> > >   struct drm_connector *list_connector;
> > >   struct radeon_connector *list_radeon_connector;
> > >   list_for_each_entry(list_connector, 
> > > &dev->mode_config.connector_list, head) {
> > >   if (connector == list_connector)
> > >   continue;
> > >   list_radeon_connector = 
> > > to_radeon_connector(list_connector);
> > >   if (radeon_connector->devices == 
> > > list_radeon_connector->devices) {
> > >   if 
> > > (drm_detect_hdmi_monitor(radeon_connector->edid)) {
> > >   if (connector->connector_

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

Hello,

After fixing the dvi/hdmi detection problem I now have another problem
with the HP EliteBook 8530p, which has Radeon 3650HD adapter.

Here's a summary of the environment:

- laptop connected to a docking station.
- external display in use, connected with DVI to the dock.
- laptop lid closed, so internal LVDS display is not used.

Now, when I start the laptop, I can see the BIOS and grub on the external DVI 
display.
All fine so far. I select the Fedora 13 kernel, and Linux starts. I see the 
Fedora
graphical boot on the external DVI display, just like it should be. GDM login 
prompt
appears on the external DVI display, still everything fine.

And then it goes wrong. After I login to X, the external display only shows the 
background
picture.. it turns out the desktop stuff has been started to the internal LVDS 
display,
which shouldn't be used at all since the laptop lid is closed!! 

When the laptop lid is closed, and external display is connected, I want to use 
only the external display..

Any ideas how to troubleshoot this one? 

-- Pasi

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi K?rkk?inen wrote:
> On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi K?rkk?inen wrote:
> > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi K?rkk?inen wrote:
> > > > > > >> >
> > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I don't 
> > > > > > >> > have anything connected
> > > > > > >> > to the HDMI connector on the laptop. There's no HDMI connector 
> > > > > > >> > on the dock, it's only in the laptop.
> > > > > > >>
> > > > > > >> Indeed that is the problem. ?On your system the HDMI and DVI 
> > > > > > >> ports
> > > > > > >> share the same encoder and DDC line so they will both come up as
> > > > > > >> connected since the line is shared. ?The driver used to check 
> > > > > > >> the edid
> > > > > > >> when the lines where shared and select HDMI or DVI based on the 
> > > > > > >> EDID,
> > > > > > >> but perhaps that got broken at some point.
> > > > > > >>
> > > > > > >
> > > > > > > Makes sense. Does some kernel option/parameter affect that?
> > > > > > 
> > > > > > No.  I'll check the code and see if I can figure out what's going 
> > > > > > on.
> > > > > > 
> > > > > 
> > > > > Ok, thanks!
> > > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > I'll be near the dock tomorrow.. So if you have a chance of looking at 
> > > > this, and want me to test something,
> > > > I could do it on thursday/friday.
> > > > 
> > > 
> > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) and 
> > > the latest 
> > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> > > behaviour was the same.
> > > 
> > > Connecting display to the DVI connector makes the HDMI connector also 
> > > show the same display, 
> > > breaking things..
> > > 
> > 
> > Here's a new log with drm.debug=4.. that's the biggest debug level that 
> > still allows me to grab
> > the whole dmesg log before it's overwritten by huge amount of debug 
> > messages.
> > 
> > Full dmesg log:
> > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> > 
> 
> Ok.. I did some debugging, and figured out how to make it work. Patch 
> attached.
> I'm not sure if this is the correct method.. someone familiar with the code 
> should review it.
> 
> 
> Some debugging information for my system (HP EliteBook 8530p):
> 
> > 
> > [drm] Radeon Display Connectors
> > [drm] Connector 0:
> > [drm]   VGA
> > [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> > [drm]   Encoders:
> > [drm] CRT1: INTERNAL_KLDSCP_DAC1
> 
> connector->devices for VGA is: 1
> 
> > [drm] Connector 1:
> > [drm]   LVDS
> > [drm]   Encoders:
> > [drm] LCD1: INTERNAL_KLDSCP_LVTMA
> 
> connector->devices for LVDS is: 2
> 
> > [drm] Connector 2:
> > [drm]   DVI-D
> > [drm]   HPD1
> > [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> > [drm]   Encoders:
> > [drm] DFP1: INTERNAL_UNIPHY
> 
> connector->devices for DVI-D is: 8
> 
> > [drm] Connector 3:
> > [drm]   HDMI-A
> > [drm]   HPD2
> > [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> > [drm]   Encoders:
> > [drm] DFP2: INTERNAL_UNIPHY
> 
> connector->devices for HDMI-A is: 128
> 
> 
> 
> The code in radeon_connectors.c in radeon_dvi_detect():
> 
>   /* multiple connectors on the same encoder with the same ddc line
>* This tends to be HDMI and DVI on the same encoder with the
>* same ddc line.  If the edid says HDMI, consider the HDMI port
>* connected and the DVI port disconnected.  If the edid doesn't
>* say HDMI, vice versa.
>*/
>   if (radeon_connector->shared_ddc && (ret == 
> connector_status_connected)) {
>   struct drm_device *dev = connector->dev;
>   struct drm_connector *list_connector;
>   struct radeon_connector *list_radeon_connector;
>   list_for_each_entry(list_connector, 
> &dev->mode_config.connector_list, head) {
>   if (connector == list_connector)
>   continue;
>   list_radeon_connector = 
> to_radeon_connector(list_connector);
>   if (radeon_connector->devices == 
> list_radeon_connector->devices) {
>   if 
> (drm_detect_hdmi_monitor(radeon_connector->edid)) {
>   if (connector->connector_type == 
> DRM_MODE_CONNECTOR_DVID) {
>   kfree(radeon_connector->edid);
>   radeon_connector->edid = NULL;
>   ret = 
> connector_status_disconnected;
>   }
>   } else {
>   if ((connector->connector_type == 
> DRM_MODE_CONNECTOR_HDMIA) ||
>   (connector->connector_type == 
> DRM_MODE_CONNECTOR_HDMIB

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi K?rkk?inen wrote:
> On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi K?rkk?inen wrote:
> > > > > >> >
> > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I don't have 
> > > > > >> > anything connected
> > > > > >> > to the HDMI connector on the laptop. There's no HDMI connector 
> > > > > >> > on the dock, it's only in the laptop.
> > > > > >>
> > > > > >> Indeed that is the problem. ?On your system the HDMI and DVI ports
> > > > > >> share the same encoder and DDC line so they will both come up as
> > > > > >> connected since the line is shared. ?The driver used to check the 
> > > > > >> edid
> > > > > >> when the lines where shared and select HDMI or DVI based on the 
> > > > > >> EDID,
> > > > > >> but perhaps that got broken at some point.
> > > > > >>
> > > > > >
> > > > > > Makes sense. Does some kernel option/parameter affect that?
> > > > > 
> > > > > No.  I'll check the code and see if I can figure out what's going on.
> > > > > 
> > > > 
> > > > Ok, thanks!
> > > > 
> > > 
> > > Hello,
> > > 
> > > I'll be near the dock tomorrow.. So if you have a chance of looking at 
> > > this, and want me to test something,
> > > I could do it on thursday/friday.
> > > 
> > 
> > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) and the 
> > latest 
> > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> > behaviour was the same.
> > 
> > Connecting display to the DVI connector makes the HDMI connector also show 
> > the same display, 
> > breaking things..
> > 
> 
> Here's a new log with drm.debug=4.. that's the biggest debug level that still 
> allows me to grab
> the whole dmesg log before it's overwritten by huge amount of debug messages.
> 
> Full dmesg log:
> http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> 

Ok.. I did some debugging, and figured out how to make it work. Patch attached.
I'm not sure if this is the correct method.. someone familiar with the code 
should review it.


Some debugging information for my system (HP EliteBook 8530p):

> 
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   VGA
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1

connector->devices for VGA is: 1

> [drm] Connector 1:
> [drm]   LVDS
> [drm]   Encoders:
> [drm] LCD1: INTERNAL_KLDSCP_LVTMA

connector->devices for LVDS is: 2

> [drm] Connector 2:
> [drm]   DVI-D
> [drm]   HPD1
> [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY

connector->devices for DVI-D is: 8

> [drm] Connector 3:
> [drm]   HDMI-A
> [drm]   HPD2
> [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> [drm]   Encoders:
> [drm] DFP2: INTERNAL_UNIPHY

connector->devices for HDMI-A is: 128



The code in radeon_connectors.c in radeon_dvi_detect():

/* multiple connectors on the same encoder with the same ddc line
 * This tends to be HDMI and DVI on the same encoder with the
 * same ddc line.  If the edid says HDMI, consider the HDMI port
 * connected and the DVI port disconnected.  If the edid doesn't
 * say HDMI, vice versa.
 */
if (radeon_connector->shared_ddc && (ret == 
connector_status_connected)) {
struct drm_device *dev = connector->dev;
struct drm_connector *list_connector;
struct radeon_connector *list_radeon_connector;
list_for_each_entry(list_connector, 
&dev->mode_config.connector_list, head) {
if (connector == list_connector)
continue;
list_radeon_connector = 
to_radeon_connector(list_connector);
if (radeon_connector->devices == 
list_radeon_connector->devices) {
if 
(drm_detect_hdmi_monitor(radeon_connector->edid)) {
if (connector->connector_type == 
DRM_MODE_CONNECTOR_DVID) {
kfree(radeon_connector->edid);
radeon_connector->edid = NULL;
ret = 
connector_status_disconnected;
}
} else {
if ((connector->connector_type == 
DRM_MODE_CONNECTOR_HDMIA) ||
(connector->connector_type == 
DRM_MODE_CONNECTOR_HDMIB)) {
kfree(radeon_connector->edid);
radeon_connector->edid = NULL;
ret = 
connector_status_disconnected;
}
 

Re: [RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 12:11:49PM -0400, Alex Deucher wrote:
> On Mon, Jun 21, 2010 at 11:03 AM, Alex Deucher  wrote:
> > On Mon, Jun 21, 2010 at 8:45 AM, Jerome Glisse  
> > wrote:
> >> On Mon, Jun 21, 2010 at 12:31:22PM +0300, Pasi Kärkkäinen wrote:
> >>> On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi Kärkkäinen wrote:
> >>> > On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi Kärkkäinen wrote:
> >>> > > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi Kärkkäinen wrote:
> >>> > > > > > > >> >
> >>> > > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I 
> >>> > > > > > > >> > don't have anything connected
> >>> > > > > > > >> > to the HDMI connector on the laptop. There's no HDMI 
> >>> > > > > > > >> > connector on the dock, it's only in the laptop.
> >>> > > > > > > >>
> >>> > > > > > > >> Indeed that is the problem.  On your system the HDMI and 
> >>> > > > > > > >> DVI ports
> >>> > > > > > > >> share the same encoder and DDC line so they will both come 
> >>> > > > > > > >> up as
> >>> > > > > > > >> connected since the line is shared.  The driver used to 
> >>> > > > > > > >> check the edid
> >>> > > > > > > >> when the lines where shared and select HDMI or DVI based 
> >>> > > > > > > >> on the EDID,
> >>> > > > > > > >> but perhaps that got broken at some point.
> >>> > > > > > > >>
> >>> > > > > > > >
> >>> > > > > > > > Makes sense. Does some kernel option/parameter affect that?
> >>> > > > > > >
> >>> > > > > > > No.  I'll check the code and see if I can figure out what's 
> >>> > > > > > > going on.
> >>> > > > > > >
> >>> > > > > >
> >>> > > > > > Ok, thanks!
> >>> > > > > >
> >>> > > > >
> >>> > > > > Hello,
> >>> > > > >
> >>> > > > > I'll be near the dock tomorrow.. So if you have a chance of 
> >>> > > > > looking at this, and want me to test something,
> >>> > > > > I could do it on thursday/friday.
> >>> > > > >
> >>> > > >
> >>> > > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) 
> >>> > > > and the latest
> >>> > > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> >>> > > > behaviour was the same.
> >>> > > >
> >>> > > > Connecting display to the DVI connector makes the HDMI connector 
> >>> > > > also show the same display,
> >>> > > > breaking things..
> >>> > > >
> >>> > >
> >>> > > Here's a new log with drm.debug=4.. that's the biggest debug level 
> >>> > > that still allows me to grab
> >>> > > the whole dmesg log before it's overwritten by huge amount of debug 
> >>> > > messages.
> >>> > >
> >>> > > Full dmesg log:
> >>> > > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> >>> > >
> >>> >
> >>> > Ok.. I did some debugging, and figured out how to make it work. Patch 
> >>> > attached.
> >>> > I'm not sure if this is the correct method.. someone familiar with the 
> >>> > code should review it.
> >>> >
> >>> >
> >>> > Some debugging information for my system (HP EliteBook 8530p):
> >>> >
> >>> > >
> >>> > > [drm] Radeon Display Connectors
> >>> > > [drm] Connector 0:
> >>> > > [drm]   VGA
> >>> > > [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> >>> > > [drm]   Encoders

Re: [RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 11:03:08AM -0400, Alex Deucher wrote:
> On Mon, Jun 21, 2010 at 8:45 AM, Jerome Glisse  wrote:
> > On Mon, Jun 21, 2010 at 12:31:22PM +0300, Pasi Kärkkäinen wrote:
> >> On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi Kärkkäinen wrote:
> >> > On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi Kärkkäinen wrote:
> >> > > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi Kärkkäinen wrote:
> >> > > > > > > >> >
> >> > > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I 
> >> > > > > > > >> > don't have anything connected
> >> > > > > > > >> > to the HDMI connector on the laptop. There's no HDMI 
> >> > > > > > > >> > connector on the dock, it's only in the laptop.
> >> > > > > > > >>
> >> > > > > > > >> Indeed that is the problem.  On your system the HDMI and 
> >> > > > > > > >> DVI ports
> >> > > > > > > >> share the same encoder and DDC line so they will both come 
> >> > > > > > > >> up as
> >> > > > > > > >> connected since the line is shared.  The driver used to 
> >> > > > > > > >> check the edid
> >> > > > > > > >> when the lines where shared and select HDMI or DVI based on 
> >> > > > > > > >> the EDID,
> >> > > > > > > >> but perhaps that got broken at some point.
> >> > > > > > > >>
> >> > > > > > > >
> >> > > > > > > > Makes sense. Does some kernel option/parameter affect that?
> >> > > > > > >
> >> > > > > > > No.  I'll check the code and see if I can figure out what's 
> >> > > > > > > going on.
> >> > > > > > >
> >> > > > > >
> >> > > > > > Ok, thanks!
> >> > > > > >
> >> > > > >
> >> > > > > Hello,
> >> > > > >
> >> > > > > I'll be near the dock tomorrow.. So if you have a chance of 
> >> > > > > looking at this, and want me to test something,
> >> > > > > I could do it on thursday/friday.
> >> > > > >
> >> > > >
> >> > > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) 
> >> > > > and the latest
> >> > > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> >> > > > behaviour was the same.
> >> > > >
> >> > > > Connecting display to the DVI connector makes the HDMI connector 
> >> > > > also show the same display,
> >> > > > breaking things..
> >> > > >
> >> > >
> >> > > Here's a new log with drm.debug=4.. that's the biggest debug level 
> >> > > that still allows me to grab
> >> > > the whole dmesg log before it's overwritten by huge amount of debug 
> >> > > messages.
> >> > >
> >> > > Full dmesg log:
> >> > > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> >> > >
> >> >
> >> > Ok.. I did some debugging, and figured out how to make it work. Patch 
> >> > attached.
> >> > I'm not sure if this is the correct method.. someone familiar with the 
> >> > code should review it.
> >> >
> >> >
> >> > Some debugging information for my system (HP EliteBook 8530p):
> >> >
> >> > >
> >> > > [drm] Radeon Display Connectors
> >> > > [drm] Connector 0:
> >> > > [drm]   VGA
> >> > > [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> >> > > [drm]   Encoders:
> >> > > [drm]     CRT1: INTERNAL_KLDSCP_DAC1
> >> >
> >> > connector->devices for VGA is: 1
> >> >
> >> > > [drm] Connector 1:
> >> > > [drm]   LVDS
> >> > > [drm]   Encoders:
> >> > > [drm]     LCD1: INTERNAL_KLDSCP_LVTMA
> >> >
> >> &

Re: Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 02:51:59PM +0200, Jerome Glisse wrote:
> On Mon, Jun 21, 2010 at 03:31:19PM +0300, Pasi Kärkkäinen wrote:
> > Hello,
> > 
> > After fixing the dvi/hdmi detection problem I now have another problem
> > with the HP EliteBook 8530p, which has Radeon 3650HD adapter.
> > 
> > Here's a summary of the environment:
> > 
> > - laptop connected to a docking station.
> > - external display in use, connected with DVI to the dock.
> > - laptop lid closed, so internal LVDS display is not used.
> > 
> > Now, when I start the laptop, I can see the BIOS and grub on the external 
> > DVI display.
> > All fine so far. I select the Fedora 13 kernel, and Linux starts. I see the 
> > Fedora
> > graphical boot on the external DVI display, just like it should be. GDM 
> > login prompt
> > appears on the external DVI display, still everything fine.
> > 
> > And then it goes wrong. After I login to X, the external display only shows 
> > the background
> > picture.. it turns out the desktop stuff has been started to the internal 
> > LVDS display,
> > which shouldn't be used at all since the laptop lid is closed!! 
> > 
> > When the laptop lid is closed, and external display is connected, I want to 
> > use only the external display..
> > 
> > Any ideas how to troubleshoot this one? 
> > 
> > -- Pasi
> > 
> 
> It's better to open bug when you face issue rather than mail, as it's
> harder to track information in mail thread than in a bug. Your issue
> is not easily fixed because there is many laptop with broken acpi which
> report wrong lid status (some of them always report lid closed what ever
> is the lid status, other always report lid open, ... i am not expert on
> how broken this is but from what i have been told i should rather consider
> drinking than trying to look into it and then go to the drinking step).
> 

Hey, I'm from Finland, so drinking and debugging is not a problem ;)

> Bottom line is that lid detection is unreliable thus so far we ignore
> it silently. I think the plan is to monitor lid status change and if
> we detect change from either open to close or close to open then we
> can start assuming that acpi lid status is reliable and act accordingly.
> 

I hate to play the "windows card" but the lid detection seems to work in 
windows.. 
so there's a way to make it work :)

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 02:45:44PM +0200, Jerome Glisse wrote:
> On Mon, Jun 21, 2010 at 12:31:22PM +0300, Pasi Kärkkäinen wrote:
> > On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi Kärkkäinen wrote:
> > > On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi Kärkkäinen wrote:
> > > > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi Kärkkäinen wrote:
> > > > > > > > >> >
> > > > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I 
> > > > > > > > >> > don't have anything connected
> > > > > > > > >> > to the HDMI connector on the laptop. There's no HDMI 
> > > > > > > > >> > connector on the dock, it's only in the laptop.
> > > > > > > > >>
> > > > > > > > >> Indeed that is the problem.  On your system the HDMI and DVI 
> > > > > > > > >> ports
> > > > > > > > >> share the same encoder and DDC line so they will both come 
> > > > > > > > >> up as
> > > > > > > > >> connected since the line is shared.  The driver used to 
> > > > > > > > >> check the edid
> > > > > > > > >> when the lines where shared and select HDMI or DVI based on 
> > > > > > > > >> the EDID,
> > > > > > > > >> but perhaps that got broken at some point.
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > > Makes sense. Does some kernel option/parameter affect that?
> > > > > > > > 
> > > > > > > > No.  I'll check the code and see if I can figure out what's 
> > > > > > > > going on.
> > > > > > > > 
> > > > > > > 
> > > > > > > Ok, thanks!
> > > > > > > 
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I'll be near the dock tomorrow.. So if you have a chance of looking 
> > > > > > at this, and want me to test something,
> > > > > > I could do it on thursday/friday.
> > > > > > 
> > > > > 
> > > > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) 
> > > > > and the latest 
> > > > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> > > > > behaviour was the same.
> > > > > 
> > > > > Connecting display to the DVI connector makes the HDMI connector also 
> > > > > show the same display, 
> > > > > breaking things..
> > > > > 
> > > > 
> > > > Here's a new log with drm.debug=4.. that's the biggest debug level that 
> > > > still allows me to grab
> > > > the whole dmesg log before it's overwritten by huge amount of debug 
> > > > messages.
> > > > 
> > > > Full dmesg log:
> > > > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> > > > 
> > > 
> > > Ok.. I did some debugging, and figured out how to make it work. Patch 
> > > attached.
> > > I'm not sure if this is the correct method.. someone familiar with the 
> > > code should review it.
> > > 
> > > 
> > > Some debugging information for my system (HP EliteBook 8530p):
> > > 
> > > > 
> > > > [drm] Radeon Display Connectors
> > > > [drm] Connector 0:
> > > > [drm]   VGA
> > > > [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> > > > [drm]   Encoders:
> > > > [drm] CRT1: INTERNAL_KLDSCP_DAC1
> > > 
> > > connector->devices for VGA is: 1
> > > 
> > > > [drm] Connector 1:
> > > > [drm]   LVDS
> > > > [drm]   Encoders:
> > > > [drm] LCD1: INTERNAL_KLDSCP_LVTMA
> > > 
> > > connector->devices for LVDS is: 2
> > > 
> > > > [drm] Connector 2:
> > > > [drm]   DVI-D
> > > > [drm]   HPD1
> > > > [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> > > > [drm]   Encoders:
> > > > [drm] DFP1: INTERNAL_UNIPHY
> > > 
> > >

Radeon 3650HD laptop LVDS lid open/closed detection problem

[Pasi Kärkkäinen]

Hello,

After fixing the dvi/hdmi detection problem I now have another problem
with the HP EliteBook 8530p, which has Radeon 3650HD adapter.

Here's a summary of the environment:

- laptop connected to a docking station.
- external display in use, connected with DVI to the dock.
- laptop lid closed, so internal LVDS display is not used.

Now, when I start the laptop, I can see the BIOS and grub on the external DVI 
display.
All fine so far. I select the Fedora 13 kernel, and Linux starts. I see the 
Fedora
graphical boot on the external DVI display, just like it should be. GDM login 
prompt
appears on the external DVI display, still everything fine.

And then it goes wrong. After I login to X, the external display only shows the 
background
picture.. it turns out the desktop stuff has been started to the internal LVDS 
display,
which shouldn't be used at all since the laptop lid is closed!! 

When the laptop lid is closed, and external display is connected, I want to use 
only the external display..

Any ideas how to troubleshoot this one? 

-- Pasi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Mon, Jun 21, 2010 at 12:23:10PM +0300, Pasi Kärkkäinen wrote:
> On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi Kärkkäinen wrote:
> > On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi Kärkkäinen wrote:
> > > > > > >> >
> > > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I don't 
> > > > > > >> > have anything connected
> > > > > > >> > to the HDMI connector on the laptop. There's no HDMI connector 
> > > > > > >> > on the dock, it's only in the laptop.
> > > > > > >>
> > > > > > >> Indeed that is the problem.  On your system the HDMI and DVI 
> > > > > > >> ports
> > > > > > >> share the same encoder and DDC line so they will both come up as
> > > > > > >> connected since the line is shared.  The driver used to check 
> > > > > > >> the edid
> > > > > > >> when the lines where shared and select HDMI or DVI based on the 
> > > > > > >> EDID,
> > > > > > >> but perhaps that got broken at some point.
> > > > > > >>
> > > > > > >
> > > > > > > Makes sense. Does some kernel option/parameter affect that?
> > > > > > 
> > > > > > No.  I'll check the code and see if I can figure out what's going 
> > > > > > on.
> > > > > > 
> > > > > 
> > > > > Ok, thanks!
> > > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > I'll be near the dock tomorrow.. So if you have a chance of looking at 
> > > > this, and want me to test something,
> > > > I could do it on thursday/friday.
> > > > 
> > > 
> > > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) and 
> > > the latest 
> > > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> > > behaviour was the same.
> > > 
> > > Connecting display to the DVI connector makes the HDMI connector also 
> > > show the same display, 
> > > breaking things..
> > > 
> > 
> > Here's a new log with drm.debug=4.. that's the biggest debug level that 
> > still allows me to grab
> > the whole dmesg log before it's overwritten by huge amount of debug 
> > messages.
> > 
> > Full dmesg log:
> > http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> > 
> 
> Ok.. I did some debugging, and figured out how to make it work. Patch 
> attached.
> I'm not sure if this is the correct method.. someone familiar with the code 
> should review it.
> 
> 
> Some debugging information for my system (HP EliteBook 8530p):
> 
> > 
> > [drm] Radeon Display Connectors
> > [drm] Connector 0:
> > [drm]   VGA
> > [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> > [drm]   Encoders:
> > [drm] CRT1: INTERNAL_KLDSCP_DAC1
> 
> connector->devices for VGA is: 1
> 
> > [drm] Connector 1:
> > [drm]   LVDS
> > [drm]   Encoders:
> > [drm] LCD1: INTERNAL_KLDSCP_LVTMA
> 
> connector->devices for LVDS is: 2
> 
> > [drm] Connector 2:
> > [drm]   DVI-D
> > [drm]   HPD1
> > [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> > [drm]   Encoders:
> > [drm] DFP1: INTERNAL_UNIPHY
> 
> connector->devices for DVI-D is: 8
> 
> > [drm] Connector 3:
> > [drm]   HDMI-A
> > [drm]   HPD2
> > [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> > [drm]   Encoders:
> > [drm] DFP2: INTERNAL_UNIPHY
> 
> connector->devices for HDMI-A is: 128
> 
> 
> 
> The code in radeon_connectors.c in radeon_dvi_detect():
> 
>   /* multiple connectors on the same encoder with the same ddc line
>* This tends to be HDMI and DVI on the same encoder with the
>* same ddc line.  If the edid says HDMI, consider the HDMI port
>* connected and the DVI port disconnected.  If the edid doesn't
>* say HDMI, vice versa.
>*/
>   if (radeon_connector->shared_ddc && (ret == 
> connector_status_connected)) {
>   struct drm_device *dev = connector->dev;
>   struct drm_connector *list_connector;
>   struct radeon_connector *l

[RFC PATCH] Re: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Sat, Jun 19, 2010 at 10:24:53PM +0300, Pasi Kärkkäinen wrote:
> On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi Kärkkäinen wrote:
> > > > > >> >
> > > > > >> > I wonder if that HDMI-0 is the key to the problem.. I don't have 
> > > > > >> > anything connected
> > > > > >> > to the HDMI connector on the laptop. There's no HDMI connector 
> > > > > >> > on the dock, it's only in the laptop.
> > > > > >>
> > > > > >> Indeed that is the problem.  On your system the HDMI and DVI ports
> > > > > >> share the same encoder and DDC line so they will both come up as
> > > > > >> connected since the line is shared.  The driver used to check the 
> > > > > >> edid
> > > > > >> when the lines where shared and select HDMI or DVI based on the 
> > > > > >> EDID,
> > > > > >> but perhaps that got broken at some point.
> > > > > >>
> > > > > >
> > > > > > Makes sense. Does some kernel option/parameter affect that?
> > > > > 
> > > > > No.  I'll check the code and see if I can figure out what's going on.
> > > > > 
> > > > 
> > > > Ok, thanks!
> > > > 
> > > 
> > > Hello,
> > > 
> > > I'll be near the dock tomorrow.. So if you have a chance of looking at 
> > > this, and want me to test something,
> > > I could do it on thursday/friday.
> > > 
> > 
> > I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) and the 
> > latest 
> > Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the 
> > behaviour was the same.
> > 
> > Connecting display to the DVI connector makes the HDMI connector also show 
> > the same display, 
> > breaking things..
> > 
> 
> Here's a new log with drm.debug=4.. that's the biggest debug level that still 
> allows me to grab
> the whole dmesg log before it's overwritten by huge amount of debug messages.
> 
> Full dmesg log:
> http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt
> 

Ok.. I did some debugging, and figured out how to make it work. Patch attached.
I'm not sure if this is the correct method.. someone familiar with the code 
should review it.


Some debugging information for my system (HP EliteBook 8530p):

> 
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   VGA
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1

connector->devices for VGA is: 1

> [drm] Connector 1:
> [drm]   LVDS
> [drm]   Encoders:
> [drm] LCD1: INTERNAL_KLDSCP_LVTMA

connector->devices for LVDS is: 2

> [drm] Connector 2:
> [drm]   DVI-D
> [drm]   HPD1
> [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY

connector->devices for DVI-D is: 8

> [drm] Connector 3:
> [drm]   HDMI-A
> [drm]   HPD2
> [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
> [drm]   Encoders:
> [drm] DFP2: INTERNAL_UNIPHY

connector->devices for HDMI-A is: 128



The code in radeon_connectors.c in radeon_dvi_detect():

/* multiple connectors on the same encoder with the same ddc line
 * This tends to be HDMI and DVI on the same encoder with the
 * same ddc line.  If the edid says HDMI, consider the HDMI port
 * connected and the DVI port disconnected.  If the edid doesn't
 * say HDMI, vice versa.
 */
if (radeon_connector->shared_ddc && (ret == 
connector_status_connected)) {
struct drm_device *dev = connector->dev;
struct drm_connector *list_connector;
struct radeon_connector *list_radeon_connector;
list_for_each_entry(list_connector, 
&dev->mode_config.connector_list, head) {
if (connector == list_connector)
continue;
list_radeon_connector = 
to_radeon_connector(list_connector);
if (radeon_connector->devices == 
list_radeon_connector->devices) {
if 
(drm_detect_hdmi_monitor(radeon_connector->edid)) {
if (connector->connector_type == 
DRM_MODE_CONNECTOR_DVID) {

KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display

[Pasi Kärkkäinen]

On Fri, Jun 18, 2010 at 09:45:22PM +0300, Pasi K?rkk?inen wrote:
> > > > >> >
> > > > >> > I wonder if that HDMI-0 is the key to the problem.. I don't have 
> > > > >> > anything connected
> > > > >> > to the HDMI connector on the laptop. There's no HDMI connector on 
> > > > >> > the dock, it's only in the laptop.
> > > > >>
> > > > >> Indeed that is the problem. ?On your system the HDMI and DVI ports
> > > > >> share the same encoder and DDC line so they will both come up as
> > > > >> connected since the line is shared. ?The driver used to check the 
> > > > >> edid
> > > > >> when the lines where shared and select HDMI or DVI based on the EDID,
> > > > >> but perhaps that got broken at some point.
> > > > >>
> > > > >
> > > > > Makes sense. Does some kernel option/parameter affect that?
> > > > 
> > > > No.  I'll check the code and see if I can figure out what's going on.
> > > > 
> > > 
> > > Ok, thanks!
> > > 
> > 
> > Hello,
> > 
> > I'll be near the dock tomorrow.. So if you have a chance of looking at 
> > this, and want me to test something,
> > I could do it on thursday/friday.
> > 
> 
> I just tried the latest Fedora 13 kernel (2.6.33.5-124.fc13.x86_64) and the 
> latest 
> Fedora development (rawhide 2.6.34-43.fc14.x86_64) kernel, but the behaviour 
> was the same.
> 
> Connecting display to the DVI connector makes the HDMI connector also show 
> the same display, 
> breaking things..
> 

Here's a new log with drm.debug=4.. that's the biggest debug level that still 
allows me to grab
the whole dmesg log before it's overwritten by huge amount of debug messages.

Full dmesg log:
http://pasik.reaktio.net/fedora/bz593429/both-internal-and-external-displays-active/dmesg-with-drmdebug4.txt


drm parts copy&pasted here:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
radeon :01:00.0: setting latency timer to 64
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0xD830
[drm] register mmio size: 65536
ATOM BIOS: HP_Wistron_Vox_M86M
[drm] Clocks initialized !
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 2012172 kiB.
[ttm] Initializing pool allocator.
[drm] radeon: 256M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
  alloc irq_desc for 33 on node -1
  alloc kstat_irqs on node -1
radeon :01:00.0: irq 33 for MSI/MSI-X
[drm] radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RV635 Microcode
platform radeon_cp.0: firmware: requesting radeon/RV635_pfp.bin
platform radeon_cp.0: firmware: requesting radeon/RV635_me.bin
platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Enabling audio support
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   LVDS
[drm]   Encoders:
[drm] LCD1: INTERNAL_KLDSCP_LVTMA
[drm] Connector 2:
[drm]   DVI-D
[drm]   HPD1
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] Connector 3:
[drm]   HDMI-A
[drm]   HPD2
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY
[drm:drm_helper_probe_single_connector_modes], VGA-1
[drm:drm_helper_probe_single_connector_modes], VGA-1 is disconnected
[drm:drm_helper_probe_single_connector_modes], LVDS-1
[drm:drm_helper_probe_single_connector_modes], Probed modes for LVDS-1
[drm:drm_mode_debug_printmodeline], Modeline 16:"1680x1050" 60 121000 1680 1744 
1840 1884 1050 1056 1062 1070 0x48 0xa
[drm:drm_mode_debug_printmodeline], Modeline 29:"1400x1050" 60 121750 1400 1488 
1632 1864 1050 1053 1057 1089 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 27:"1280x1024" 60 109000 1280 1368 
1496 1712 1024 1027 1034 1063 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 28:"1440x900" 60 106500 1440 1528 
1672 1904 900 903 909 934 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 26:"1280x960" 60 101250 1280 1360 
1488 1696 960 963 967 996 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 25:"1280x854" 60 89250 1280 1352 
1480 1680 854 857 867 887 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 24:"1280x800" 60 83500 1280 1352 
1480 1680 800 803 809 831 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 23:"1280x720" 60 74500 1280 1344 
1472 1664 720 723 728 748 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 22:"1152x768" 60 71750 1152 1216 
1328 1504 768 771 781 798 0x0 0x6
[drm:drm_mode_debug_printmodeline], Modeline 21:"1024x768" 60 63500 1024 1072 
1176 1328 768 771 775 798 0x0 0x6
[drm:drm_mode_de