[Bug 102384] corruption/glitch on right click contextual menu, drop down menus with DRI3 and glamor in kwin

2017-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102384

--- Comment #1 from Barto  ---
Created attachment 133736
  --> https://bugs.freedesktop.org/attachment.cgi?id=133736=edit
glxinfo

glxinfo output

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 102384] New: corruption/glitch on right click contextual menu, drop down menus with DRI3 and glamor in kwin

2017-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102384

Bug ID: 102384
   Summary: corruption/glitch on right click contextual menu, drop
down menus with DRI3 and glamor in kwin
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/Radeon
  Assignee: xorg-driver-ati@lists.x.org
  Reporter: mister.free...@laposte.net
QA Contact: xorg-t...@lists.x.org

Created attachment 133735
  --> https://bugs.freedesktop.org/attachment.cgi?id=133735=edit
xorg log

Hello,

I have a radeon HD4650 Pcie ( chipset RV730 pro ), I use archlinux 64 bits,
xf86-video-ati 1:7.9.0-2,

as desktop I use plasma 5 ( kde ), opengGL2 is enabled in kwin for desktop
effects,

DRI 3 and glamour are enabled, tearfree is "off", and I have set vsync in kwin
to "automatic", I see no tearing, all is ok in videos and 3D games,

my radeon conf file in /etc/X11/xorg.conf.d/

Section "Device"
Identifier "Radeon"
Driver "radeon"
Option "TearFree" "off"
Option "DRI" "3"
Option "AccelMethod" "glamor"
EndSection

my problem : I notice sometimes glitchs, corruption when I do a righ-click (
contextual menu ) and when I use "dropdown menu" ( in dolphin, firefox ), the
problem occurs randomly and not often ( 10% of chance to trigger the bug when I
do a right click for the contextual menu ),

when the bug occurs I see in the contextual menu a mix of displays ( for
example if dolphin is in the background and firefox on top then in the
contextual menu I can see a mix of Dolphin/firefox screens, all is mixed
together, and sometimes colors blink inside the contextual menu )

if I retry then the bug disapears immediatly and the contextual menu is
correctly displayed,

it's a random bug, sometimes this bug will not occur for 2 hours, and when the
bugs occurs it will disapear quickly if I re-click with the mouse,

is it a known bug when dri3 and glamour are enabled in kwin/plasma 5 ?

thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 101998] X server 1.19.3 failure with amdgpu (radeon M295X) on Ubuntu HWE16.04 kernel 4.10.0-28

2017-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101998

Michel Dänzer  changed:

   What|Removed |Added

 CC||ago...@nvidia.com
   Assignee|xorg-driver-ati@lists.x.org |xorg-t...@lists.x.org
  Component|Driver/AMDgpu   |Driver/modesetting

--- Comment #37 from Michel Dänzer  ---
I was able to reproduce the problem. It's a modesetting driver bug, this code
in ms_dirty_update:

msPixmapPrivPtr ppriv =
msGetPixmapPriv(>drmmode, ent->slave_dst);

probably needs to be:

msPixmapPrivPtr ppriv =
msGetPixmapPriv(>drmmode, ent->slave_dst->master_pixmap);

otherwise it tries to access random memory when the slave screen doesn't use
the modesetting driver.

There might be more related issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 101998] X server 1.19.3 failure with amdgpu (radeon M295X) on Ubuntu HWE16.04 kernel 4.10.0-28

2017-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101998

--- Comment #36 from Michel Dänzer  ---
(In reply to Meik Neubauer from comment #35)
> [...] from what I can get out of gdb is that the call stack is pretty clear
> [...]

Right, which is why I'm saying we don't need more backtraces right now.


> The question is, which routine is responsible for setting up the structure in
> ent->slave_dst->drawable.pScreen and why is that not done correctly.

As I said in comment 15, the question is how ppriv->notify_on_damage ends up
being TRUE in ms_dirty_update. The only way I can see that being the case is if
 msRequestSharedPixmapNotifyDamage was called before, but xf86-video-amdgpu
doesn't have any code calling the RequestSharedPixmapNotifyDamage hook.


> > We really need answers to the questions in comment 27.
> 
> I cannot set up a second machine. Due to network security restrictions here
> I cannot connect between two PCs. And I do not have an external monitor in
> any other location. So running a remote gdb debugging session is out of
> reach.

None of the questions in comment 27 are related to remote access or gdb.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 101998] X server 1.19.3 failure with amdgpu (radeon M295X) on Ubuntu HWE16.04 kernel 4.10.0-28

2017-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101998

--- Comment #35 from Meik Neubauer  ---
(In reply to Michel Dänzer from comment #34)
> gdb cannot resolve symbols with only the core dump. Anyway, the screenshots
> showed the interesting parts of the backtrace. The problem is I have no clue
> how it could end up running the crashing code path.

I am not sure I understand this correctly. Maybe I am not getting the point
here, because I am not familiar with the intel platform (working on old
Mainframes instead), but from what I can get out of gdb is that the call stack
is pretty clear and the failure occurs in
hw/xfree86/drives/modesetting/driver.c in routine ms_dirty_update where
ent->slave_dst->drawable.pScreen-> SharedPixmapNotifyDamage(ent->slave_dst);
loads a zero address for the call.

The question is, which routine is responsible for setting up the structure in
ent->slave_dst->drawable.pScreen
and why is that not done correctly.

The related data areas seem to be all available in the core dump.

I agree that backtracking this is painful bit-counting, but it does not seem
out of reach.

I would first try to identify the routine that sets up
ent->slave_dst->drawable.pScreen

I have not tried this yet, because without a complete build setup on my machine
this is cumbersome task. I guess that with a ready development environment on
your side this is much easier to find out.


> We really need answers to the questions in comment 27.

I cannot set up a second machine. Due to network security restrictions here I
cannot connect between two PCs. And I do not have an external monitor in any
other location. So running a remote gdb debugging session is out of reach.
Also, this is my everyday production laptop, so I cannot conduct any wild
experiments on it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 98046] iMac11,1 (RV770/M98L [Mobility Radeon HD 4850]) needs nomodeset to boot

2017-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98046

--- Comment #9 from James Cameron  ---
Other than reverting the series in comment 4, I've no solution.  Once I had
that workaround, I was mostly happy.  I wanted to find the underlying problem
and upstream it, but ran out of time.

At one stage I was using "avivotool regs pll1" to confirm the PLL registers,
comparing between last working kernel version, latest kernel, and my kernel
with the series reverted.

My notes have outstanding questions that I didn't get to resolve; 

1. how to achieve a dot clock of 36 instead of 30, given that 36
works for me?

2. why is RADEON_PLL_PREFER_LOW_REF_DIV set given that the bit is only used
when RADEON_PLL_LEGACY is set?

3. why set RADEON_PLL_PREFER_MINM_OVER_MAXP given that it limits the ref_div to
7 yet the system has already chosen 2 instead of 5.

Hope that helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 98046] iMac11,1 (RV770/M98L [Mobility Radeon HD 4850]) needs nomodeset to boot

2017-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98046

--- Comment #8 from Justin Thiessen  ---
Hi,

I'm still seeing this issue with an iMac11,1 with the identical graphics
(RV770/M98L [Mobility Radeon HD 4850])

This is with kubuntu 17.04:

kernel: 4.10.0-32-generic

radeon driver info:

libdrm-radeon1:amd64   2.4.76-1
xserver-xorg-video-radeon  1:7.9.0-0ubuntu1

I only get a working main display using 'nomodeset', which of course is
disabling the radeon driver.

Any suggested patches or things to try?

Thanks,

Justin Thiessen

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati