[Bug 86635] Live for Speed and gallium nine, missing objects
https://bugs.freedesktop.org/show_bug.cgi?id=86635 --- Comment #5 from Balázs Vinarz --- Created attachment 111378 --> https://bugs.freedesktop.org/attachment.cgi?id=111378&action=edit picture one more thing. looks like every car has a black more skin, also in the interior. i reinstalled the d3d9_43 and compiler also. if i turn the gallium-nine off, then the cars are looking normal. look at the picture attached -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/98b6e606/attachment.html>
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 lct at mail.ru changed: What|Removed |Added Priority|medium |high --- Comment #30 from lct at mail.ru --- Still experiencing this with kernel 3.17-1 and latest Mesa from Manjaro. Experiencing it even in Enlightment e17 (version e19) environiment, when hardware OpenGL compositing is selected. If I select software compositing, then this issue disappears. Also, in KDE 4.14 I get random kernel hardlocks and freezes, I never had. I wonder if this issue is connected. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/d07edb97/attachment.html>
[Bug 86635] Live for Speed and gallium nine, missing objects
https://bugs.freedesktop.org/show_bug.cgi?id=86635 --- Comment #4 from Balázs Vinarz --- yeey, its works. you are awesome :) A8-3850 stock w/o nine: 45fps with nine: 65fps what about hyperz, is it enabled by default? or if you are running with nine there is no speed up? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/a4e311df/attachment.html>
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #13 from Florent Bondoux --- Created attachment 111376 --> https://bugs.freedesktop.org/attachment.cgi?id=111376&action=edit kernel log with patch Hello Michel, The patch didn't work (tested on 3.18.1). Both warnings triggered, see attached suspend/resume log. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/c3e97bb0/attachment.html>
[Bug 86635] Live for Speed and gallium nine, missing objects
https://bugs.freedesktop.org/show_bug.cgi?id=86635 --- Comment #3 from David Heidelberg (okias) --- https://launchpad.net/~oibaf/+archive/ubuntu/gallium-nine from this PPA it should be probably already fixed (using our repo) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/bc2a3376/attachment.html>
3.19-rc1 errors when opening LID
On Friday 26 December 2014 16:12:49 Rafael J. Wysocki wrote: > On Wednesday, December 24, 2014 07:51:48 PM Pali Rohár wrote: > > --nextPart5943893.pKyMBm5Emp > > Content-Type: Text/Plain; > > > > charset="utf-8" > > > > Content-Transfer-Encoding: quoted-printable > > > > Hello! > > > > With new 3.19-rc1 kernel every time when I open LID on my > > laptop, kernel pr= > > > ints these error lines to dmesg: > Does your syste suspend when the lid is closed and resume when > it is open? > No, I disabled all autosuspend and autohibernate settings. When I close LID system is running. > > > [25568.448566] acpi MSFT:00: Cannot transition to power > > state D3cold fo= r parent in (unknown) > > [25568.448572] acpi INT33C2:00: Cannot transition to non-D0 > > state from D3 [25568.448577] acpi MSFT0002:00: Cannot > > transition to power state D3cold fo= r parent in (unknown) > > [25568.448581] acpi ELAN1010:00: Cannot transition to power > > state D3cold fo= r parent in (unknown) > > [25568.448587] acpi INT33C3:00: Cannot transition to non-D0 > > state from D3 [25568.448590] acpi INT33C0:00: Cannot > > transition to non-D0 state from D3 [25568.448594] acpi > > INT33C1:00: Cannot transition to non-D0 state from D3 > > [25568.448598] acpi INT33C4:00: Cannot transition to non-D0 > > state from D3 [25568.448602] acpi INT33C5:00: Cannot > > transition to non-D0 state from D3 [25568.448623] acpi > > device:41: Cannot transition to power state D3cold for = > > parent in (unknown) > > [25568.448627] acpi INT33C6:00: Cannot transition to non-D0 > > state from D3 > > All of the above mean that power transitions were not carried > out for some devices, because they were in unexpected power > states to start with. > > They are devices on the Intel LPSS as far as I can say (CCing > Mika and Andy). > Just to note: all above acpi devices do not exist in 3.13 kernel, at least I do not see them in /sys/bus/acpi/. > > [25568.448890] pci_bus :01: Allocating resources > > [25568.448905] i915 :00:02.0: BAR 6: [??? 0x > > flags 0x2] has bog= us alignment > > [25568.449064] i915 :00:02.0: BAR 6: [??? 0x > > flags 0x2] has bog= us alignment > > [25568.449472] i915 :00:02.0: BAR 6: [??? 0x > > flags 0x2] has bog= us alignment > > > > With older kernel (3.13) I do not see these errors, so it is > > regression. > > It only is a regression if it leads to functional problems. > Do you see any? > Ok. I do not see functional problems, but I see above messages in dmesg log every time when I open LID. > > Ca=n you look at it? If it is needed, I can provide other > > logs, ACPI/DSTD dump= s, etc. > > It looks like 3.13 didn't try to use some devices that are now > used in 3.19-rc1 and something doesn't work entirely as > expected. -- Pali Rohár pali.rohar at gmail.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/60b6fc1b/attachment-0001.sig>
[PATCH] nouveau: fix ambiguous backlight controls
On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler wrote:
> If a display supports backlight control using the nouveau driver, and
> also supports standard ACPI backlight control, there will be two sets of
> controls.
>
> /sys/class/backlight/acpi_video0
> /sys/class/backlight/nv_backlight
>
> This creates ambiguity because these controls can be out of sync with
> each other. One could be at 100% while the other is at 0% and the
> actual display brightness depends on which one was used last. This also
> creates anomalies in Powertop which will show two values for brightness
> with potentially different values.
>
> Fix this ambiguity by having the nouveau driver only enable its
> backlight controls if the standard ACPI controls are not present.
>
> Signed-off-by: Jeremiah Mahler
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index e566c5b..3a52bd4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
> struct nvif_device *device = &drm->device;
> struct drm_connector *connector;
>
> + if (acpi_video_backlight_support()) {
None of the other drivers have this. Is nouveau somehow different
than, say, radeon in this respect?
Unfortunately the backlight situation is pretty fubar'd... sometimes
the acpi controls don't work, sometimes the card controls don't work,
sometimes they both work but in different ways (and then everyone's
favourite -- neither works, and there's some third platform thing).
I'm pretty sure this code existed before, but got removed. See commit
bee564430feec1175ee64bcfd4913cacc519f817 and the previous commit
5bead799d3f8 before that. The ping-pong is probably not the right way
to go.
> + dev_info(dev->dev, "Standard ACPI backlight control
> supported, disabling local control.\n");
> + return 0;
> + }
> +
> list_for_each_entry(connector, &dev->mode_config.connector_list,
> head) {
> if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
> connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
3.19-rc1 errors when opening LID
On Wednesday, December 24, 2014 07:51:48 PM Pali Rohár wrote: > > --nextPart5943893.pKyMBm5Emp > Content-Type: Text/Plain; > charset="utf-8" > Content-Transfer-Encoding: quoted-printable > > Hello! > > With new 3.19-rc1 kernel every time when I open LID on my laptop, kernel pr= > ints these error lines to dmesg: Does your syste suspend when the lid is closed and resume when it is open? > [25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaim= > ed register detected. Please use the i915.mmio_debug=3D1 to debug this prob= > lem. > [25566.368134] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed reg= > ister before interrupt > [25566.368192] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaim= > ed register detected. Please use the i915.mmio_debug=3D1 to debug this prob= > lem. > [25566.368232] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaim= > ed register detected. Please use the i915.mmio_debug=3D1 to debug this prob= > lem.<4>[25568.446011] i915 :00:02.0: BAR 6: [??? 0x flags 0x2]= > =20 > has bogus alignment The above messages are from i915 and don't seem to be related to ACPI. > [25568.447018] pci_bus :02: Allocating resources > [25568.447055] pci_bus :03: Allocating resources > [25568.447135] pci_bus :04: Allocating resources > [25568.447168] pci_bus :05: Allocating resources > [25568.447195] pci_bus :06: Allocating resources > [25568.447228] pci_bus :0e: Allocating resources > [25568.447323] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > [25568.447557] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > [25568.447735] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > [25568.447847] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > [25568.448399] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > [25568.448438] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment The above too. > [25568.448566] acpi MSFT:00: Cannot transition to power state D3cold fo= > r parent in (unknown) > [25568.448572] acpi INT33C2:00: Cannot transition to non-D0 state from D3 > [25568.448577] acpi MSFT0002:00: Cannot transition to power state D3cold fo= > r parent in (unknown) > [25568.448581] acpi ELAN1010:00: Cannot transition to power state D3cold fo= > r parent in (unknown) > [25568.448587] acpi INT33C3:00: Cannot transition to non-D0 state from D3 > [25568.448590] acpi INT33C0:00: Cannot transition to non-D0 state from D3 > [25568.448594] acpi INT33C1:00: Cannot transition to non-D0 state from D3 > [25568.448598] acpi INT33C4:00: Cannot transition to non-D0 state from D3 > [25568.448602] acpi INT33C5:00: Cannot transition to non-D0 state from D3 > [25568.448623] acpi device:41: Cannot transition to power state D3cold for = > parent in (unknown) > [25568.448627] acpi INT33C6:00: Cannot transition to non-D0 state from D3 All of the above mean that power transitions were not carried out for some devices, because they were in unexpected power states to start with. They are devices on the Intel LPSS as far as I can say (CCing Mika and Andy). > [25568.448890] pci_bus :01: Allocating resources > [25568.448905] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > [25568.449064] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > [25568.449472] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog= > us alignment > > With older kernel (3.13) I do not see these errors, so it is regression. It only is a regression if it leads to functional problems. Do you see any? > Ca=n you look at it? If it is needed, I can provide other logs, ACPI/DSTD > dump= > s, etc. It looks like 3.13 didn't try to use some devices that are now used in 3.19-rc1 and something doesn't work entirely as expected. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
[PATCH] nouveau: fix ambiguous backlight controls
Ilia,
On Fri, Dec 26, 2014 at 04:39:08PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler
> wrote:
> > If a display supports backlight control using the nouveau driver, and
> > also supports standard ACPI backlight control, there will be two sets of
> > controls.
> >
> > /sys/class/backlight/acpi_video0
> > /sys/class/backlight/nv_backlight
> >
> > This creates ambiguity because these controls can be out of sync with
> > each other. One could be at 100% while the other is at 0% and the
> > actual display brightness depends on which one was used last. This also
> > creates anomalies in Powertop which will show two values for brightness
> > with potentially different values.
> >
> > Fix this ambiguity by having the nouveau driver only enable its
> > backlight controls if the standard ACPI controls are not present.
> >
> > Signed-off-by: Jeremiah Mahler
> > ---
> > drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > index e566c5b..3a52bd4 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > @@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
> > struct nvif_device *device = &drm->device;
> > struct drm_connector *connector;
> >
> > + if (acpi_video_backlight_support()) {
>
> None of the other drivers have this. Is nouveau somehow different
> than, say, radeon in this respect?
>
> Unfortunately the backlight situation is pretty fubar'd... sometimes
> the acpi controls don't work, sometimes the card controls don't work,
> sometimes they both work but in different ways (and then everyone's
> favourite -- neither works, and there's some third platform thing).
> I'm pretty sure this code existed before, but got removed. See commit
> bee564430feec1175ee64bcfd4913cacc519f817 and the previous commit
> 5bead799d3f8 before that. The ping-pong is probably not the right way
> to go.
>
I was not aware of that change. But you are right, it took out what I
was trying to put back in.
Thanks for the helpful information. I will have to rethink this fix.
[...]
--
- Jeremiah Mahler
[Bug 86635] Live for Speed and gallium nine, missing objects
https://bugs.freedesktop.org/show_bug.cgi?id=86635 --- Comment #2 from David Heidelberg (okias) --- AMD A8-3870K (gpu OC at 720Mhz) with Nine:avg 80 fps without Nine: avg 50 fps Please try Mesa from https://github.com/iXit/Mesa-3D/commits/master repository (fix is not merged in upstream yet). It should work now, little bit blinking background of steering wheel, otherwise no issues. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/9012b5e1/attachment.html>
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
On Fri, 2014-12-26 at 12:17 +0900, Michel Dänzer wrote:
> On 26.12.2014 12:10, Kertesz Laszlo wrote:
> > On Fri, 2014-12-26 at 10:26 +0900, Michel Dänzer wrote:
> >> On 26.12.2014 09:01, Kertesz Laszlo wrote:
> >>> Attached gdb trace (crashed on latest git x server).
> >>
> >> Did it include commit 70a6f65f9e2b26ef7539dcacfcfea927bc1f13fd ('glamor:
> >> Make sure Xvideo source image data is properly aligned')? If not, does
> >> that help by any chance?
> >>
> >> If not, can you make sure debugging symbols are available for
> >> /usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so, and get another
> >> backtrace?
> >>
> >>
> > Yes i do have that commit (last is modesetting: Add vblank
> > synchronization support when using Present.).
> > And i enabled debug in the xserver with --enable-debug, is there
> > something else i need to add for libglamoregl?
>
> If you're building and installing packages from xserver Git, you may
> need to install the corresponding debugging package. Otherwise, make
> sure /usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so is actually
> the one you built from Git, and that it doesn't get stripped.
>
>
Ok, rebuilt the xserver package with debugging symbols (seems that
checkinstall strips stuff by default). I got a bigger gdb.txt. See if it
helps.
-- next part --
Continuing.
Program received signal SIGABRT, Aborted.
0x7f62dd2e5107 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 0x7f62dd2e5107 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 321
selftid = 321
#1 0x7f62dd2e64e8 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7fff09a46f97, sa_sigaction
= 0x7fff09a46f97}, sa_mask = {__val = {140062595550753, 140062573768354, 806,
4, 140733355154400, 50883329280,
140062522211584, 4294967296, 0, 0, 0, 21474836480,
140062595550279, 140733355154552, 140062627950592, 140062595565928}}, sa_flags
= -604721240,
sa_restorer = 0x7f62dbf4b1c0 <__PRETTY_FUNCTION__.42275>}
sigs = {__val = {32, 0 }}
#2 0x7f62dd2de226 in __assert_fail_base (fmt=0x7f62dd414968 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n",
assertion=assertion at entry=0x7f62dbf4afa8 "y + fbo_y_off + h <=
pixmap_priv->base.fbo->height", file=file at entry=0x7f62dbf4aea2
"glamor_pixmap.c", line=line at entry=806,
function=function at entry=0x7f62dbf4b1c0 <__PRETTY_FUNCTION__.42275>
"_glamor_upload_bits_to_pixmap_texture") at assert.c:92
str = 0x23eff80 "\220\351\065\002"
total = 4096
#3 0x7f62dd2de2d2 in __GI___assert_fail (assertion=assertion at
entry=0x7f62dbf4afa8 "y + fbo_y_off + h <= pixmap_priv->base.fbo->height",
file=file at entry=0x7f62dbf4aea2 "glamor_pixmap.c",
line=line at entry=806, function=function at entry=0x7f62dbf4b1c0
<__PRETTY_FUNCTION__.42275> "_glamor_upload_bits_to_pixmap_texture") at
assert.c:101
No locals.
#4 0x7f62dbf3c1fe in _glamor_upload_bits_to_pixmap_texture
(pixmap=0x2342210, format=6406, type=5121, no_alpha=0, revert=0, swap_rb=3,
x=0, y=0, w=320, h=241, stride=320, bits=0x2373178, pbo=0)
at glamor_pixmap.c:806
fbo_x_off = 0
fbo_y_off = 0
pixmap_priv = 0x23fe730
vertices = {-1, -1, 1, -1, 1, 1, -1, 1}
texcoords_inv = {0, 0, 1, 0, 1, 1, 0, 1}
ptexcoords =
dst_xscale =
dst_yscale =
tex = 0
need_free_bits = 0
__PRETTY_FUNCTION__ = "_glamor_upload_bits_to_pixmap_texture"
#5 0x7f62dbf3caf8 in glamor_upload_sub_pixmap_to_texture (pixmap=0x141,
x=321, x at entry=0, y=6, y at entry=0, w=320, h=241, stride=1667525480, stride
at entry=320, bits=0x2373178, pbo=0)
at glamor_pixmap.c:1031
force_clip = -602555200
__FUNCTION__ = "glamor_upload_sub_pixmap_to_texture"
__PRETTY_FUNCTION__ = "glamor_upload_sub_pixmap_to_texture"
#6 0x7f62dbf44ae3 in glamor_xv_put_image (port_priv=0x1a33a38,
pDrawable=0x23e5d80, src_x=, src_y=,
drw_x=, drw_y=, src_w=320,
src_h=239, drw_w=63, drw_h=47, id=842094169,
buf=0x2373178 '\374' , '\373' ,
"\372\373", '\372' ,
"\371\372\372\372\372\372\372\372\372\371\371\371\372\371\372\372\372\371\372\372\372\372\372\372\372\372\372\371\371\371\372\371\371\372\372\371\372\371\371\371\371\370\361\336Ǹ\257\241\217\205sqnpqlgefghijhhmwuqo"...,
width=320, height=240, sync=0, clipBoxes=0x7fff09a46000)
at glamor_xv.c:454
pScreen = 0x154c8f0
srcPitch = 320
srcPitch2 = 160
top = 0
nlines = 241
s2offset =
s3offset =
#7 0x0048d9ef in xf86XVPutImage (pDraw=0x23e5d80, pPort=0x1a34340,
pGC=, src_x=, src_y=,
src_w=, src_h=239, drw_x=0, drw_y=0,
drw_w=63, drw_h=47, format=0x19a9690,
data=0x237317
[PATCH] nouveau: fix ambiguous backlight controls
If a display supports backlight control using the nouveau driver, and
also supports standard ACPI backlight control, there will be two sets of
controls.
/sys/class/backlight/acpi_video0
/sys/class/backlight/nv_backlight
This creates ambiguity because these controls can be out of sync with
each other. One could be at 100% while the other is at 0% and the
actual display brightness depends on which one was used last. This also
creates anomalies in Powertop which will show two values for brightness
with potentially different values.
Fix this ambiguity by having the nouveau driver only enable its
backlight controls if the standard ACPI controls are not present.
Signed-off-by: Jeremiah Mahler
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index e566c5b..3a52bd4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = &drm->device;
struct drm_connector *connector;
+ if (acpi_video_backlight_support()) {
+ dev_info(dev->dev, "Standard ACPI backlight control supported,
disabling local control.\n");
+ return 0;
+ }
+
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
--
2.1.4
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #14 from Christian König --- (In reply to Ãyvind Saether from comment #13) > on 3.18.1, could this be because the card is factory overclocked? Yes, that's possible. If you activate UVD you must downclock the system clock for it to work reliable. Not sure if we have implemented that correctly for SI. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/dbd0d4d6/attachment.html>
[Bug 87741] VA-API state tracker in radeon results in green screen.
https://bugs.freedesktop.org/show_bug.cgi?id=87741 Bug ID: 87741 Summary: VA-API state tracker in radeon results in green screen. Product: Mesa Version: 10.4 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: barz621 at gmail.com Created attachment 111367 --> https://bugs.freedesktop.org/attachment.cgi?id=111367&action=edit dmesg As the title suggests. Exported LIBVA_DRIVER_NAME=gallium and using gst-vaapi you get a green screen while the sound plays. It seems that decoding works -UVD clocks change speed- but the video ends up green. Youtube and E19 using gst for video all have the same behavior. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/64bce82d/attachment.html>
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 Ãyvind Saether changed: What|Removed |Added CC||oyvinds at everdot.org --- Comment #13 from Ãyvind Saether --- Created attachment 111366 --> https://bugs.freedesktop.org/attachment.cgi?id=111366&action=edit dmesg 3.18.1 with drm debug=0x06 [6.976062] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks! [6.976064] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to raise UVD clocks (-110). [6.976066] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-110). on 3.18.1, could this be because the card is factory overclocked? [5.613512] [drm:radeon_pm_print_states] 4 Power State(s) [5.613512] [drm:radeon_pm_print_states] State 0: [5.613513] [drm:radeon_pm_print_states] Default [5.613514] [drm:radeon_pm_print_states] 16 PCIE Lanes [5.613514] [drm:radeon_pm_print_states] 1 Clock Mode(s) [5.613515] [drm:radeon_pm_print_states] 0 e: 86 m: 120 v: 1210 [5.613516] [drm:radeon_pm_print_states] State 1: Performance [5.613517] [drm:radeon_pm_print_states] 16 PCIE Lanes [5.613517] [drm:radeon_pm_print_states] 3 Clock Mode(s) [5.613518] [drm:radeon_pm_print_states] 0 e: 30 m: 50 v: 825 [5.613519] [drm:radeon_pm_print_states] 1 e: 45 m: 1225000 v: 900 [5.613520] [drm:radeon_pm_print_states] 2 e: 100m: 1225000 v: 1210 [5.613520] [drm:radeon_pm_print_states] State 2: [5.613521] [drm:radeon_pm_print_states] 16 PCIE Lanes [5.613521] [drm:radeon_pm_print_states] 3 Clock Mode(s) [5.613522] [drm:radeon_pm_print_states] 0 e: 45 m: 1225000 v: 900 [5.613522] [drm:radeon_pm_print_states] 1 e: 45 m: 1225000 v: 900 [5.613523] [drm:radeon_pm_print_states] 2 e: 100m: 1225000 v: 1210 [5.613524] [drm:radeon_pm_print_states] State 3: [5.613524] [drm:radeon_pm_print_states] 1 PCIE Lanes [5.613525] [drm:radeon_pm_print_states] 3 Clock Mode(s) [5.613526] [drm:radeon_pm_print_states] 0 e: 30 m: 50 v: 825 [5.613526] [drm:radeon_pm_print_states] 1 e: 30 m: 50 v: 825 [5.613527] [drm:radeon_pm_print_states] 2 e: 30 m: 50 v: 825 [5.613557] [drm] radeon: power management initialized -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/e3cde57d/attachment-0001.html>
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
On 26.12.2014 12:10, Kertesz Laszlo wrote:
> On Fri, 2014-12-26 at 10:26 +0900, Michel Dänzer wrote:
>> On 26.12.2014 09:01, Kertesz Laszlo wrote:
>>> Attached gdb trace (crashed on latest git x server).
>>
>> Did it include commit 70a6f65f9e2b26ef7539dcacfcfea927bc1f13fd ('glamor:
>> Make sure Xvideo source image data is properly aligned')? If not, does
>> that help by any chance?
>>
>> If not, can you make sure debugging symbols are available for
>> /usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so, and get another
>> backtrace?
>>
>>
> Yes i do have that commit (last is modesetting: Add vblank
> synchronization support when using Present.).
> And i enabled debug in the xserver with --enable-debug, is there
> something else i need to add for libglamoregl?
If you're building and installing packages from xserver Git, you may
need to install the corresponding debugging package. Otherwise, make
sure /usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so is actually
the one you built from Git, and that it doesn't get stripped.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
[PATCH v7 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
Hi Philipp,
Thank you for the patch.
On Tuesday 23 December 2014 14:09:16 Philipp Zabel wrote:
> Decrementing the reference count of the previous endpoint node allows to
> use the of_graph_get_next_endpoint function in a for_each_... style macro.
> All current users of this function that pass a non-NULL prev parameter
> (coresight, rcar-du, imx-drm, soc_camera, and omap2-dss) are changed to
> not decrement the passed prev argument's refcount themselves.
>
> Signed-off-by: Philipp Zabel
> Acked-by: Mauro Carvalho Chehab
> Acked-by: Mathieu Poirier
> ---
> Changes since v6:
> - Added omap2-dss.
> - Added Mathieu's ack.
> ---
> drivers/coresight/of_coresight.c | 13 ++---
> drivers/gpu/drm/imx/imx-drm-core.c| 13 ++---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 ---
For rcar-du,
Acked-by: Laurent Pinchart
> drivers/media/platform/soc_camera/soc_camera.c| 3 ++-
> drivers/of/base.c | 9 +
> drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +--
> 6 files changed, 12 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/coresight/of_coresight.c
> b/drivers/coresight/of_coresight.c index 5030c07..349c88b 100644
> --- a/drivers/coresight/of_coresight.c
> +++ b/drivers/coresight/of_coresight.c
> @@ -52,15 +52,6 @@ of_coresight_get_endpoint_device(struct device_node
> *endpoint) endpoint, of_dev_node_match);
> }
>
> -static struct device_node *of_get_coresight_endpoint(
> - const struct device_node *parent, struct device_node *prev)
> -{
> - struct device_node *node = of_graph_get_next_endpoint(parent, prev);
> -
> - of_node_put(prev);
> - return node;
> -}
> -
> static void of_coresight_get_ports(struct device_node *node,
> int *nr_inport, int *nr_outport)
> {
> @@ -68,7 +59,7 @@ static void of_coresight_get_ports(struct device_node
> *node, int in = 0, out = 0;
>
> do {
> - ep = of_get_coresight_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
> if (!ep)
> break;
>
> @@ -140,7 +131,7 @@ struct coresight_platform_data
> *of_get_coresight_platform_data( /* Iterate through each port to discover
> topology */
> do {
> /* Get a handle on a port */
> - ep = of_get_coresight_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
> if (!ep)
> break;
>
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c index b250130..fed627d 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -436,15 +436,6 @@ static uint32_t imx_drm_find_crtc_mask(struct
> imx_drm_device *imxdrm, return 0;
> }
>
> -static struct device_node *imx_drm_of_get_next_endpoint(
> - const struct device_node *parent, struct device_node *prev)
> -{
> - struct device_node *node = of_graph_get_next_endpoint(parent, prev);
> -
> - of_node_put(prev);
> - return node;
> -}
> -
> int imx_drm_encoder_parse_of(struct drm_device *drm,
> struct drm_encoder *encoder, struct device_node *np)
> {
> @@ -456,7 +447,7 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
> for (i = 0; ; i++) {
> u32 mask;
>
> - ep = imx_drm_of_get_next_endpoint(np, ep);
> + ep = of_graph_get_next_endpoint(np, ep);
> if (!ep)
> break;
>
> @@ -504,7 +495,7 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
> return -EINVAL;
>
> do {
> - ep = imx_drm_of_get_next_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
> if (!ep)
> break;
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 0c5ee61..480c4d9 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -206,7 +206,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, enum rcar_du_encoder_type enc_type =
> RCAR_DU_ENCODER_NONE;
> struct device_node *connector = NULL;
> struct device_node *encoder = NULL;
> - struct device_node *prev = NULL;
> + struct device_node *ep_node = NULL;
> struct device_node *entity_ep_node;
> struct device_node *entity;
> int ret;
> @@ -225,11 +225,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, entity_ep_node = of_parse_phandle(ep->local_node,
> "remote-endpoint", 0);
>
> while (1) {
> - struct device_node *ep_node;
> -
> - ep_node = of_graph_get_next_endpoint(entity, prev);
> - of_node_put(prev);
> - prev = ep_node;
> + ep_node = of_graph_get_next_endpoint(entit
[PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd
Hi Thierry, On Thursday 25 December 2014 14:20:59 Thierry Reding wrote: > On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote: > > This small patch-set, was created to solve the bug described at > > https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when > > trying use amdkfd driver on Kaveri). It replaces the previous patch-set > > called [PATCH 0/3] Use workqueue for device init in amdkfd > > (http://lists.freedesktop.org/archives/dri-devel/2014-December/074401.html > > ) > > > > That bug appears only when radeon, amdkfd and amd_iommu_v2 are compiled > > inside the kernel (not as modules). In that case, the correct loading > > order, as determined by the exported symbol used by each driver, is > > not enforced anymore and the kernel loads them based on who was linked > > first. That makes radeon load first, amdkfd second and amd_iommu_v2 > > third. > > > > Because the initialization of a device in amdkfd is initiated by radeon, > > and can only be completed if amdkfd and amd_iommu_v2 were loaded and > > initialized, then in the case mentioned above, this initalization fails > > and there is a kernel panic as some pointers are not initialized but > > used nontheless. > > > > To solve this bug, this patch-set moves iommu/ before gpu/ in > > drivers/Makefile and also moves amdkfd/ before radeon/ in > > drivers/gpu/drm/Makefile. > > > > The rationale is that in general, AMD GPU devices are dependent on AMD > > IOMMU controller functionality to allow the GPU to access a process's > > virtual memory address space, without the need for pinning the memory. > > That's why it makes sense to initialize the iommu/ subsystem ahead of the > > gpu/ subsystem. > > I strongly object to this patch set. This makes assumptions about how > the build system influences probe order. That's bad because seemingly > unrelated changes could easily break this in the future. > > We already have ways to solve this kind of dependency (driver probe > deferral), and I think you should be using it to solve this particular > problem rather than some linking order hack. While I agree with you that probe deferral is the way to go, I believe linkage ordering can still be used as an optimization to avoid deferring probe in the most common cases. I'm thus not opposed to moving iommu/ earlier in link order (provided we can properly test for side effects, as the jump is pretty large), but not as a replacement for probe deferral. > Coincidentally there's a separate thread currently going on that deals > with IOMMUs and probe order. The solution being worked on is currently > somewhat ARM-specific, so adding a couple of folks for visibility. It > looks like we're going to need something more generic since this is a > problem that even the "big" architectures need to solve. -- Regards, Laurent Pinchart
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
On 26.12.2014 09:01, Kertesz Laszlo wrote:
> Attached gdb trace (crashed on latest git x server).
Did it include commit 70a6f65f9e2b26ef7539dcacfcfea927bc1f13fd ('glamor:
Make sure Xvideo source image data is properly aligned')? If not, does
that help by any chance?
If not, can you make sure debugging symbols are available for
/usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so, and get another
backtrace?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
[PULL] drm-exynos-next 2014-12-22
On 2014ë 12ì 22ì¼ 22:04, Gustavo Padovan wrote: > Hi Dave, > > Here goes a bunch of clean up for the exynos driver. I've posted this work in > the mailing list twice but never got a review on it, first time was about a Never no. I already had a review and they - your first time patch set - had been merged to exynos-drm-next-todo. I was moving them to exynos-drm-next locally but one of your patch set was not reasonable to me so I gave you one comment. After that, you posted next patch set which include new changes and patches just 9 days ago. So they should also be reviewed enough at least for two weeks. Please, do not hurry. Such big changes should really be reviewed enough. I will wait for other reviews and them merge them if reviewed enough. If nobody have reviews then I will merge them. So please, don't worry about that. Thanks, Inki Dae > month ago. This work is the first building block for the atomic modesetting on > exynos. > > In the pull request we have: > > - removal of struct exynos_drm_overlay and struct exynos_drm_manager. > exynos_drm_overlay was merged with exynos_drm_plane and exynos_drm_manager > with exynos_drm_crtc removing two extra and unnecessary abstractions levels > from the exynos code. It also makes understanding of the code easier since > now we talk using known names like CRTC and Planes instead of manager and > overlay. > > - removal of DPMS operations from places where it is not need, e.g., updating > planes. > > - unification of plane update on exynos_update_plane(). Now all pieces of code > that wants to update a plane should be using this function. > > There are also some smalls fixes and clean ups. > > Gustavo > > --- > The following changes since commit 4e0cd68115620bc3236ff4e58e4c073948629b41: > > drm: sti: fix module compilation issue (2014-12-15 17:07:57 +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/padovan/drm-exynos-next.git > master > > for you to fetch changes up to 31dd160f42138fff62a7c9ba71cd0f47b678fe4d: > > drm/exynos: create exynos_check_plane() (2014-12-19 15:41:05 -0200) > > > Gustavo Padovan (21): > drm/exynos: move to_exynos_crtc() macro to main header > drm/exynos: expose struct exynos_drm_crtc > drm/exynos: remove exynos_drm_crtc_plane_* wrappers > drm/exynos: remove struct exynos_drm_overlay > drm/exynos/fimd: don't initialize 'ret' variable in fimd_probe() > drm/exynos/vidi: remove useless ops->commit() > drm/exynos: Don't touch DPMS when updating overlay planes > drm/exynos: don't do any DPMS operation while updating planes > drm/exynos: remove exynos_plane_commit() wrapper > drm/exynos: unify plane update on exynos_update_plane() > drm/exynos: call exynos_update_plane() directly on page flips > drm/exynos: remove exynos_drm_crtc_mode_set_commit() > drm/exynos: rename base object of struct exynos_drm_crtc to 'base' > drm/exynos: add pipe param to exynos_drm_crtc_create() > drm/exynos: remove pipe member of struct exynos_drm_manager > drm/exynos: move 'type' from manager to crtc struct > drm/exynos: remove drm_dev from struct exynos_drm_manager > drm/exynos: remove struct exynos_drm_manager > drm/exynos: don't duplicate drm_display_mode in fimd context > drm/exynos: remove mode_set() ops from exynos_crtc > drm/exynos: create exynos_check_plane() > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 185 > +-- > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 8 ++- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 83 +++-- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 181 > + > drivers/gpu/drm/exynos/exynos_drm_plane.c | 138 > + > drivers/gpu/drm/exynos/exynos_drm_plane.h | 17 +++-- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 135 > +--- > drivers/gpu/drm/exynos/exynos_mixer.c | 159 > +++ > 8 files changed, 412 insertions(+), 494 deletions(-) >
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Michel Dänzer changed: What|Removed |Added Component|DRM/Radeon |Drivers/Gallium/radeonsi Version|unspecified |git Product|DRI |Mesa Summary|Please add Image support|[OpenCL] Please add Image ||support -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/fd885c49/attachment.html>
[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume
https://bugs.freedesktop.org/show_bug.cgi?id=86267 Michel Dänzer changed: What|Removed |Added Attachment #110555|0 |1 is obsolete|| --- Comment #13 from Michel Dänzer --- Created attachment 111362 --> https://bugs.freedesktop.org/attachment.cgi?id=111362&action=edit Keep GART table mapped across suspend/resume Does this patch help? Note that it's just an incomplete proof of concept, but it should at least help narrow down the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/b856f290/attachment.html>
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #12 from Michel Dänzer --- Created attachment 111361 --> https://bugs.freedesktop.org/attachment.cgi?id=111361&action=edit Keep GART table mapped across suspend/resume Does this patch help? Note that it's just an incomplete proof of concept, but it should at least help narrow down the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/090ba220/attachment-0001.html>
[Bug 87738] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Bug ID: 87738 Summary: Please add Image support Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: mercen45 at gmail.com Hi, Image support is required by darktable (RAW photos processing) as can be seen in the following output, from runnind darktable -d opencl: [opencl_init] opencl related configuration options: [opencl_init] [opencl_init] opencl: 0 [opencl_init] opencl_library: '' [opencl_init] opencl_memory_requirement: 768 [opencl_init] opencl_memory_headroom: 300 [opencl_init] opencl_device_priority: '*/!0,*/*/*' [opencl_init] opencl_size_roundup: 16 [opencl_init] opencl_async_pixelpipe: 0 [opencl_init] opencl_synch_cache: 0 [opencl_init] opencl_number_event_handles: 25 [opencl_init] opencl_micro_nap: 1000 [opencl_init] opencl_use_pinned_memory: 0 [opencl_init] opencl_use_cpu_devices: 0 [opencl_init] opencl_avoid_atomics: 0 [opencl_init] opencl_omit_whitebalance: 0 [opencl_init] [opencl_init] trying to load opencl library: '' [opencl_init] opencl library 'libOpenCL' found on your system and loaded [opencl_init] found 1 platform [opencl_init] found 1 device [opencl_init] discarding device 0 `AMD OLAND' due to missing image support. [opencl_init] no suitable devices found. [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system. [opencl_init] initial status of opencl enabled flag is OFF. Not sure if anything else is needed to get OpenCL to work in darktable but it would be very sweet to be able to get that with open source drivers. Thanks, Thomas -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141226/8347ba40/attachment.html>
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
On Fri, 2014-12-26 at 10:26 +0900, Michel Dänzer wrote:
> On 26.12.2014 09:01, Kertesz Laszlo wrote:
> > Attached gdb trace (crashed on latest git x server).
>
> Did it include commit 70a6f65f9e2b26ef7539dcacfcfea927bc1f13fd ('glamor:
> Make sure Xvideo source image data is properly aligned')? If not, does
> that help by any chance?
>
> If not, can you make sure debugging symbols are available for
> /usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so, and get another
> backtrace?
>
>
Yes i do have that commit (last is modesetting: Add vblank
synchronization support when using Present.).
And i enabled debug in the xserver with --enable-debug, is there
something else i need to add for libglamoregl?
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Attached gdb trace (crashed on latest git x server).
--
O zi buna,
Kertesz Laszlo
-- next part --
Continuing.
Program received signal SIGABRT, Aborted.
0x7f95897a5107 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 0x7f95897a5107 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 1782
selftid = 1782
#1 0x7f95897a64e8 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7fffb8735f97, sa_sigaction
= 0x7fffb8735f97}, sa_mask = {__val = {140280234577441, 140280212795042, 806,
4, 140736287947904, 49479023872,
140280161238272, 4294967296, 0, 0, 0, 21474836480,
140280234576967, 140736287948056, 140280267075584, 140280234592616}}, sa_flags
= -2009026648, sa_restorer = 0x7f958840b1c0}
sigs = {__val = {32, 0 }}
#2 0x7f958979e226 in __assert_fail_base (fmt=0x7f95898d4968 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n",
assertion=assertion at entry=0x7f958840afa8 "y + fbo_y_off + h <=
pixmap_priv->base.fbo->height", file=file at entry=0x7f958840aea2
"glamor_pixmap.c", line=line at entry=806,
function=function at entry=0x7f958840b1c0
"_glamor_upload_bits_to_pixmap_texture") at assert.c:92
str = 0x1b5f570 ""
total = 4096
#3 0x7f958979e2d2 in __GI___assert_fail (assertion=0x7f958840afa8 "y +
fbo_y_off + h <= pixmap_priv->base.fbo->height", file=0x7f958840aea2
"glamor_pixmap.c", line=806,
function=0x7f958840b1c0 "_glamor_upload_bits_to_pixmap_texture") at
assert.c:101
No locals.
#4 0x7f95883fc1fe in ?? () from
/usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so
No symbol table info available.
#5 0x7f95883fcaf8 in ?? () from
/usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so
No symbol table info available.
#6 0x7f9588404ae3 in ?? () from
/usr/lib/x86_64-linux-gnu/xorg/modules/libglamoregl.so
No symbol table info available.
#7 0x0048d9ef in ?? ()
No symbol table info available.
#8 0x004d5859 in ?? ()
No symbol table info available.
#9 0x00437c87 in ?? ()
No symbol table info available.
#10 0x0043bd1b in ?? ()
No symbol table info available.
#11 0x7f9589791b45 in __libc_start_main (main=0x427350, argc=12,
argv=0x7fffb8734358, init=, fini=,
rtld_fini=, stack_end=0x7fffb8734348)
at libc-start.c:287
result =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -517365550660209946,
4354901, 140736287949648, 0, 0, 517494095386489574, 575018433031549670},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0,
0x594380 <__libc_csu_init>, 0x7fffb8734358}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 5849984}}}
not_first_call =
#12 0x0042737e in _start ()
No symbol table info available.
