dri-devel June 2013

dri-devel@lists.freedesktop.org

132 participants
727 discussions

[Bug 44772] New: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
by bugzilla-daemon＠freedesktop.org 11 Jul '13

11 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=44772 Bug #: 44772 Summary: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes Classification: Unclassified Product: DRI Version: XOrg CVS Platform: All OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: h.judt(a)gmx.at Resuming after hibernation fails sometimes. After reading the snapshot (the percentage reached 100%), the screen would switch back, but instead the monitor goes black and turns off and the complete system hangs. No ssh or sysreq keys work, everything is dead. Some things I noticed that might help: * It does not occur with nomodeset=1. * You don't need X to reproduce this, just console with modesetting enabled is enough. * It is not reproducible reliably, but the likelyness that it will occur is unfortunately not small (I'd say 3-4 out of 10 attempts). * The fastboot kernel parameter is not related to it. That is all with vanilla kernel. Now enter tuxonice, because it provides more information. Tuxonice reads the atomic copy first (20%..40%..60%..80%->100%). Now, it would switch on tuxoniceui and show the progress for reading in the caches. However, in the problem case the switch does not happen, because the system hangs as described for the vanilla kernel (no ssh, sysreq). At this point, one has to push the reset button to reboot. However, tuxonice has a nice feature: It will detect the image, and that it has resumed from this image before. It then asks the user whether he wants to try resuming from that same image again or remove the image and continue booting. If one presses 'C' to resume from the image, this time everything works and the system is fully functional. In fact, it's a 100% chance that the screen does not get black or the system freezes. The issue does not occur at certain cycles, sometimes three hibernation->resume cycles go well, then the fourth and fifth will not work, then the next four are ok and so on... So, I believe there is some issue with hardware initialization and hibernation. It might be that something does not really finish in time. What could there be wrong? This is with vanilla-3.2-rc5 and 3.2-rc7-tuxonice (see http://git.tuxonice.net/?p=tuxonice-head.git;a=summary), but I guess all 3.2-rc kernels will show the same problem. I had troubles hibernating with vanilla-3.2-final, so I could not test this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 12

[Bug 65723] New: Xonotic glsl 1.30 broken
by bugzilla-daemon＠freedesktop.org 11 Jul '13

11 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=65723 Priority: medium Bug ID: 65723 Assignee: dri-devel(a)lists.freedesktop.org Summary: Xonotic glsl 1.30 broken Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: jrch2k10(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa since glsl was enable by default xonotic 0.6 have heavy render issues my entire stack is git and my card is an 7770. you can download from here the entire apitrace file[apitrace 3.0] https://docs.google.com/uc?export=download&confirm=2qiw&id=0B29SlCylOCovb2N… thanks in advance -- You are receiving this mail because: You are the assignee for the bug.

1 8

[PATCH] drm: drm init call takes large time
by Abbas Raza 08 Jul '13

08 Jul '13

From: Abbas Raza <Abbas_Raza(a)mentor.com> DRM_INFO calls in the drm init routines are causing a large delay at boot time due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO to DRM_DEBUG reduces startup time to < 3ms. Signed-off-by: Abbas Raza <Abbas_Raza(a)mentor.com> CC: David Airlie <airlied(a)linux.ie> Acked-by: Dmitry Eremin-Solenikov <dmitry_eremin(a)mentor.com> --- drivers/gpu/drm/drm_irq.c | 6 +++--- drivers/gpu/drm/drm_platform.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index c798eea..782f5ff 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -252,13 +252,13 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs) if (!dev->_vblank_time) goto err; - DRM_INFO("Supports vblank timestamp caching Rev 1 (10.10.2010).\n"); + DRM_DEBUG("Supports vblank timestamp caching Rev 1 (10.10.2010).\n"); /* Driver specific high-precision vblank timestamping supported? */ if (dev->driver->get_vblank_timestamp) - DRM_INFO("Driver supports precise vblank timestamp query.\n"); + DRM_DEBUG("Driver supports precise vblank timestamp query.\n"); else - DRM_INFO("No driver support for vblank timestamp query.\n"); + DRM_DEBUG("No driver support for vblank timestamp query.\n"); /* Zero per-crtc vblank stuff */ for (i = 0; i < num_crtcs; i++) { diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c index 82431dc..7649963 100644 --- a/drivers/gpu/drm/drm_platform.c +++ b/drivers/gpu/drm/drm_platform.c @@ -92,7 +92,7 @@ int drm_get_platform_dev(struct platform_device *platdev, mutex_unlock(&drm_global_mutex); - DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n", + DRM_DEBUG("Initialized %s %d.%d.%d %s on minor %d\n", driver->name, driver->major, driver->minor, driver->patchlevel, driver->date, dev->primary->index); -- 1.8.2

2 2

[PATCH v2 0/3] drm/cma: use prime helpers instead GEM CMA specific dma_buf functionality
by Joonyoung Shim 08 Jul '13

08 Jul '13

Hello, This is the second version patchset. GEM CMA supports dma_buf but it needs GEM CMA specific functionality for dma_buf. We can use prime helpers for dma_buf by commit 89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so this patchset is to replace from using GEM CMA specific functions to using prime helpers. To Laurent, It is merged a patch to cache mapping from DRM Prime, can this patchset get your ack? Changes from v1: - rebased from drm-next branch of git://people.freedesktop.org/~airlied/linux - fix to check whether gem_prime_mmap field is NULL from "drm: add mmap function to prime helpers" commit Joonyoung Shim (3): drm: add mmap function to prime helpers drm/cma: add low-level hook functions to use prime helpers drm/cma: remove GEM CMA specific dma_buf functionality drivers/gpu/drm/drm_gem_cma_helper.c | 293 +++++------------------------------ drivers/gpu/drm/drm_prime.c | 8 +- include/drm/drmP.h | 2 + include/drm/drm_gem_cma_helper.h | 13 +- 4 files changed, 60 insertions(+), 256 deletions(-)

3 6

exynos-drm-next todo work.
by Inki Dae 08 Jul '13

08 Jul '13

Hi all, I'd like to discuss Exynos DRM TODO work. There are features we have to solve and implement. The purpose of this email is to share what we have to do so that other guys can be involved without duplicated work. 1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler device instead of VP device. And now exynos drm driver has gscaler module as a sub module of IPP framework. However, this gscaler module is very specific to IPP framework so it's not easy to reuse this module. So maybe we need so many works for it. Video play back path using post process (AS IS): MFC--------IPP--------KMS---------FIMD or HDMI Ideal video play back path using post process (TO BE): MFC--------KMS--------FIMD or HDMI The above scenario is to send decoded image data (YUV format) to display device via post process. However, we don't really need to use IPP framework in case of using gscaler as VP. All we have to do is to call kms interface (setplane) for it like we did before. 2. More features for HDMI sound support - we need to implement Exynos ALSA SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit rate, and so on from user side should be sent to drm hdmi driver via ALSA interface and the ALSA SoC DAI driver. As of now, it seems like that we should implement this driver like OMAP does because there is no common framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver: in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces of DSS driver directly. I think we could implement ALSA SoC DAI driver in more generic way if we first implement common framework for it. Welcome to any volunteer and other opinions. Thanks, Inki Dae

4 5

[Bug 43114] New: Can't set high engine clock for RadeonHD 6620G
by bugzilla-daemon＠bugzilla.kernel.org 04 Jul '13

04 Jul '13

https://bugzilla.kernel.org/show_bug.cgi?id=43114 Summary: Can't set high engine clock for RadeonHD 6620G Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: runetmember(a)gmail.com Regression: No APU model: A8-3500M with Radeon HD 6620G. Laptop model: Acer Aspire 7560G. According to official specs of this APU http://www.amd.com/us/products/notebook/apu/mainstream/Pages/mainstream.asp… https://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units#c… GPU core clock on high profile should be 444 MHz, but even when I set high profile manually ~# cat /sys/class/drm/card0/device/power_method profile ~# cat /sys/class/drm/card0/device/power_profile high GPU core clock is not 444 MHz anyway, even below 200 MHz: ~$ cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 200000 kHz current engine clock: 7990 kHz default memory clock: 667000 kHz Maybe output of radeon_pm_info is incorrect, because change between different profiles and dynpm make no difference in radeon_pm_info information. Reproduceable with Linux 3.2 and Linux 3.4rc3. dmesg of 3.4rc3 boot process attached. Is there any additional information I need to provide? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 4

[PATCH RFC v4 0/3] Armada DRM driver
by Russell King - ARM Linux 02 Jul '13

02 Jul '13

Quite a number of things has changed since the last revision in the core code - notably the move to use drm_plane for overlay, and the limited and restricted use of dma_buf so that gem objects can be passed to the GALCORE code and libbmm contiguous video frames can be imported into DRM. As I thought, this does require quite a number of new system calls, but the case which I care more about (vlc) doesn't pass rendered frames directly to the X server by physical address, it's not something I'm particularly concerned about - for vlc and the "normal" Xv protocol we can cache four DRM gem objects with their framebuffers pre-prepared meaning we just copy the frame and call the DRM set_plane function. What the loss of the create_phys() interface does mean is that the modified gstreamer gstbmmxvimagesink plugin will not work; it will need to be updated. I do *not* intend to support the hacky bidirectional Xv SHM hack which Marvell came up with there! I've left out the TDA998x changes and the final patch which depends on those changes which add the HDMI output for the cubox, so this series will be lacking the final parts of connector support. It is probable that the patch from the previous series can be trivially applied to this (or easily adapted if not.) Other changes: - the crtc exports a few attributes now for setting the colour transform mode. (CCIR601/709 to Computer vs "Studio" RGB). An automatic mode for these settings provided depending on selected resolution. - overlay has working brightness/contrast/saturation settings, but not hue - not worked that bit out yet. - hardware ARGB cursor support only in this version. - backend ops are now called variants, because the structure started to contain other stuff other than just function pointers. Armada510 backend moved to a separate file. - features requiring the SPU_ADV_REG (only present on Armada 510) can be disabled by the variant structure - such as interlace and ARGB cursor. - use of page_alloc() reduced down to 8K, enough to store the hardware cursor. This is all that that allocation was really used for anyway. - now uses a common kfifo queue to free used framebuffers at the appropriate time, both from the crtc code and the drm_plane code, rather than having this logic in several places. kfifo is a weird API and there's a note in the driver about that. - framebuffers now carry their configuration with them, to save having the pixel format decode scattered in several places in the driver. - power down FIFOs and RAMs not being used, and keep them powered down where possible. - minimum framebuffer size added, moved out from the X server driver. - maximum horizontal resolution dropped to 1920 to avoid a potential problem with V scaling (the RAM is apparantly 1920 pixels by 3 lines.) - protection preventing various gem objects being used in unexpected ways added - eg, you can't create a framebuffer from a cursor gem object or an imported object which is non-contiguous. - full range of colorkey modes for video supported (hey, it's just drm plane properties!) - loads of smaller cleanups, and a number of checkpatch fixes. Things left to do, in no particular order: - Creation of planar YUV formatted framebuffers - I suspect the planar YUV formats are not supported for graphic framebuffers even though Marvell document the register settings. (Where do you program the base addresses of the U and V planes?) Not a high priority as Vmeta produces UYVY encoded frames and it's more efficient to keep the native format. - Gamma support if anyone cares. Again, not high priority. - Resolution of the clocking conundrum. - Resolution of the DT specification conundrum (super-device?) - Specification of DRM connectors (DT but how?), their configuration, what they're connected to and what fixed format(s) they support. - CMA or no CMA - I've added a comment pointing out additional concerns about how to get the physical address from CMA. I think for most platforms this driver will be used on, the device address and physical address will be the same, but _conceptually_ they have never been the same in the kernel. - DCON support... I have no use for this, and the information in my documentation is pretty damned poor, so much so that I'm reluctant to try prodding around with it, especially as some of it is self-contradictory. Anyone who really cares about this can look at the issues there. Stuff omitted: - the DRM refcounting bug fix which breaks the i915 driver (but without it, booting with this driver results in a leaked refcount on the framebuffer thanks what I consider to be a bug in the DRM crtc code.) So don't boot this without something reporting itself as being connected with a valid mode.

7 24

[Bug 66317] New: FlightGear 2.10 crashes on load
by bugzilla-daemon＠freedesktop.org 02 Jul '13

02 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=66317 Priority: medium Bug ID: 66317 Assignee: dri-devel(a)lists.freedesktop.org Summary: FlightGear 2.10 crashes on load Severity: normal Classification: Unclassified OS: All Reporter: marvin24(a)gmx.de Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Flightgear crashes while initializing some llvm stuff: .... Animated jetways ... initialized KMA20 audio panel initialized KI266 dme indicator #0 initialized loading scenario 'nimitz_demo' Unable to find target for this triple (no targets are registered) Program received signal SIGSEGV, Segmentation fault. 0x00007fffead86a0d in create_jit_texture_type (gallivm=0x0, struct_name=0x7fffeb02d6a0 "texture") at draw/draw_llvm.c:124 124 LLVMTargetDataRef target = gallivm->target; (gdb) bt #0 0x00007fffead86a0d in create_jit_texture_type (gallivm=0x0, struct_name=0x7fffeb02d6a0 "texture") at draw/draw_llvm.c:124 #1 0x00007fffead87886 in create_jit_types (variant=0x9d7f9a0) at draw/draw_llvm.c:467 #2 0x00007fffead87b4b in draw_llvm_create_variant (llvm=0x1194ff0, num_inputs=3, key=0x7fffffffbca0) at draw/draw_llvm.c:577 #3 0x00007fffead8e62a in llvm_middle_end_prepare (middle=0x11a59d0, in_prim=0, opt=7, max_vertices=0x11a2bb8) at draw/draw_pt_fetch_shade_pipeline_llvm.c:235 #4 0x00007fffeac512ce in vsplit_prepare (frontend=0x11a2b80, in_prim=0, middle=0x11a59d0, opt=7) at draw/draw_pt_vsplit.c:174 #5 0x00007fffeac418e3 in draw_pt_arrays (draw=0x11939e0, prim=0, start=0, count=1) at draw/draw_pt.c:135 #6 0x00007fffeac426d9 in draw_vbo (draw=0x11939e0, info=0x7fffffffc130) at draw/draw_pt.c:543 #7 0x00007fffeab3ab8f in draw_arrays (draw=0x11939e0, mode=0, start=0, count=1) at ../../src/mesa/state_tracker/st_draw_feedback.c:101 #8 0x00007fffeab3b4a9 in st_feedback_draw_vbo (ctx=0x112dde0, prims=0x9d7f158, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=1, tfb_vertcount=0x0) at ../../src/mesa/state_tracker/st_draw_feedback.c:269 #9 0x00007fffeab3283d in st_RasterPos (ctx=0x112dde0, v=0x7fffffffc960) at ../../src/mesa/state_tracker/st_cb_rasterpos.c:256 #10 0x00007fffeaa74ee8 in rasterpos (x=0, y=0, z=0, w=1) at ../../src/mesa/main/rastpos.c:61 #11 0x00007fffeaa74f88 in _mesa_RasterPos2i (x=0, y=0) at ../../src/mesa/main/rastpos.c:80 #12 0x00007ffff4f4c7d6 in fntBitmapFont::puts(float*, float, float, char const*) () from /usr/lib64/libplibfnt.so.0 #13 0x00007ffff516ddcb in puFont::drawString(char const*, int, int) () from /usr/lib64/libplibpu.so.0 #14 0x00007ffff5165bee in puButton::draw(int, int) () from /usr/lib64/libplibpu.so.0 #15 0x00007ffff51679da in puGroup::draw(int, int) () from /usr/lib64/libplibpu.so.0 #16 0x00007ffff51679da in puGroup::draw(int, int) () from /usr/lib64/libplibpu.so.0 #17 0x00007ffff51644c9 in puDisplay() () from /usr/lib64/libplibpu.so.0 #18 0x00000000009aea3b in SGPuDrawable::drawImplementation(osg::RenderInfo&) const () #19 0x00007ffff6b37667 in osgUtil::RenderLeaf::render(osg::RenderInfo&, osgUtil::RenderLeaf*) () from /usr/lib64/libosgUtil.so.80 #20 0x00007ffff6b317e5 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #21 0x00007ffff6b31824 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #22 0x00007ffff6b387c3 in osgUtil::RenderStage::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #23 0x00007ffff6b3bc96 in osgUtil::RenderStage::drawInner(osg::RenderInfo&, osgUtil::RenderLeaf*&, bool&) () from /usr/lib64/libosgUtil.so.80 #24 0x00007ffff6b3b8ba in osgUtil::RenderStage::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #25 0x00007ffff6b454a5 in osgUtil::SceneView::draw() () from /usr/lib64/libosgUtil.so.80 #26 0x00007ffff67673f5 in osgViewer::Renderer::cull_draw() () from /usr/lib64/libosgViewer.so.80 #27 0x00007ffff60fa5f9 in osg::GraphicsContext::runOperations() () from /usr/lib64/libosg.so.80 #28 0x00007ffff679c964 in osgViewer::ViewerBase::renderingTraversals() () from /usr/lib64/libosgViewer.so.80 #29 0x000000000099fca1 in fgOSMainLoop() () #30 0x00000000005ca1e5 in fgMainInit(int, char**) () #31 0x000000000059d514 in main () (gdb) quit Happens with both R600_LLVM=1 or 0. -- You are receiving this mail because: You are the assignee for the bug.

1 2

RADEON / DPM: GPU cannot properly up-clock
by Joshua C. 01 Jul '13

01 Jul '13

First of all thank you guys for pushing this out! Great work! I tried the latest code in drm-next-3.11-wip (up to commit b3c1e0c3ba885db44 “drm/radeon: fix endian issues in atombios dpm code”) in connection with the latest radeon_ucode (latest update on 2013-06-26). I also reintroduced the debugfs info so that I can better observe the gpu-settings. For this I put back the following patch: diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 7ba5d6f..9367234 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev) ret = device_create_file(rdev->dev, &dev_attr_power_method); if (ret) DRM_ERROR("failed to create device file for power method\n"); + + if (radeon_debugfs_pm_init(rdev)) { + DRM_ERROR("Failed to register debugfs file for PM!\n"); + } + DRM_INFO("radeon: dpm initialized\n"); } -- 1.8.2.1 Everything works fine, however I think that my gpu (ati 6670, see below) doesn't reclock properly (OR doesn't reclock at all). I observed the gpu-temps and compared those with the readings when using “profile” and “dynpm”. Usually (with dynpm) the temps stay low and jump up when I start glxgears or any HD-movie. With the latest dpm my temps and the gpu stay in the lowest profile all the time. It doesn't reclock even if I start any demanding work like HD-Movie. Dmesg shows this: *** [ 1.307529] == power state 0 == [ 1.307530] ui class: none [ 1.307531] internal class: boot [ 1.307532] caps: [ 1.307533] uvd vclk: 0 dclk: 0 [ 1.307534] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307535] power level 1 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307536] power level 2 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307537] status: c r b [ 1.307538] == power state 1 == [ 1.307539] ui class: performance [ 1.307539] internal class: none [ 1.307540] caps: [ 1.307541] uvd vclk: 0 dclk: 0 [ 1.307542] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307543] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307544] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307544] status: [ 1.307545] == power state 2 == [ 1.307546] ui class: none [ 1.307546] internal class: uvd [ 1.307547] caps: video [ 1.307549] uvd vclk: 70000 dclk: 56000 [ 1.307549] power level 0 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307550] power level 1 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307551] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307552] status: [ 1.311858] switching from power state: [ 1.311859] ui class: none [ 1.311860] internal class: boot [ 1.311860] caps: [ 1.311861] uvd vclk: 0 dclk: 0 [ 1.311862] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311863] power level 1 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311864] power level 2 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311865] status: c b [ 1.311866] switching to power state: [ 1.311866] ui class: performance [ 1.311867] internal class: none [ 1.311868] caps: [ 1.311869] uvd vclk: 0 dclk: 0 [ 1.311869] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311870] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.311871] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.311872] status: r and later (other dmesg output is attached) [ 1.360509] switching from power state: [ 1.360510] ui class: performance [ 1.360510] internal class: none [ 1.360511] caps: [ 1.360511] uvd vclk: 0 dclk: 0 [ 1.360512] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.360512] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360513] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360513] status: c r [ 1.360514] switching to power state: [ 1.360514] ui class: performance [ 1.360515] internal class: none [ 1.360515] caps: [ 1.360515] uvd vclk: 0 dclk: 0 [ 1.360516] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.360516] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360517] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360517] status: c r *** The radeon_pm_info shows all the time: [root@localhost ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 800000 kHz current engine clock: 99990 kHz default memory clock: 1000000 kHz current memory clock: 150000 kHz voltage: 1100 mV PCIE lanes: 16 When using the “dynpm” settings I could see the voltage dropping back to 900mV (as in performace, power level 0) but now it stays high all the time. When playing a HD-Moving I can see the film in a “slow-motion” which also confirms that the gpu doesn't reclock. Setting dynpm reclocks fine and the HD-movie plays smoothly. My gpu is: 01:00.0 VGA compatible controller: ATI Technologies Inc Turks XT [AMD Radeon HD 6600 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e194 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 56 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at fe620000 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at e000 [size=256] Expansion ROM at fe600000 [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 256 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 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee0f00c Data: 41d2 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon Can some take a look at this? Thanks, joshua

3 5

[Bug 65310] New: [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576
by bugzilla-daemon＠freedesktop.org 01 Jul '13

01 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=65310 Priority: medium Bug ID: 65310 Assignee: dri-devel(a)lists.freedesktop.org Summary: [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576 Severity: critical Classification: Unclassified OS: Linux (All) Reporter: David.Ronis(a)McGill.CA Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa I'm trying to build today's git/master on a slackware box. i get the following: /bin/sh ../../../../libtool --tag=CC --mode=compile /usr/bin/gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"9.2.0\" -DPACKAGE_STRING=\"Mesa\ 9.2.0\" -DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi\?product=Mesa\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"9.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1 -DHAVE_PTHREAD=1 -DHAVE_LIBEXPAT=1 -I. -I../../../../src/gallium/drivers -I../../../../include -I../../../../include -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS -I/usr/include/libdrm -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -MT nvc0_vbo.lo -MD -MP -MF .deps/nvc0_vbo.Tpo -c -o nvc0_vbo.lo nvc0_vbo.c libtool: compile: /usr/bin/gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -DPACKAGE_VERSION=\"9.2.0\" "-DPACKAGE_STRING=\"Mesa 9.2.0\"" "-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\"" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"9.2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1 -DHAVE_PTHREAD=1 -DHAVE_LIBEXPAT=1 -I. -I../../../../src/gallium/drivers -I../../../../include -I../../../../include -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DHAVE_ALIAS -I/usr/include/libdrm -march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -MT nvc0_vbo.lo -MD -MP -MF .deps/nvc0_vbo.Tpo -c nvc0_vbo.c -fPIC -DPIC -o .libs/nvc0_vbo.o /tmp/cc6sw2Xe.s: Assembler messages: /tmp/cc6sw2Xe.s:1270: Error: missing or invalid displacement expression `-8589934576' /tmp/cc6sw2Xe.s:1277: Error: missing or invalid displacement expression `-8589934560' /tmp/cc6sw2Xe.s:1284: Error: missing or invalid displacement expression `-8589934544' /tmp/cc6sw2Xe.s:2073: Error: missing or invalid displacement expression `-8589934576' /tmp/cc6sw2Xe.s:2079: Error: missing or invalid displacement expression `-8589934560' /tmp/cc6sw2Xe.s:2085: Error: missing or invalid displacement expression `-8589934544' /tmp/cc6sw2Xe.s:2091: Error: missing or invalid displacement expression `-8589934528' /tmp/cc6sw2Xe.s:2097: Error: missing or invalid displacement expression `-8589934512' /tmp/cc6sw2Xe.s:2103: Error: missing or invalid displacement expression `-8589934496' /tmp/cc6sw2Xe.s:2109: Error: missing or invalid displacement expression `-8589934480' make: *** [nvc0_vbo.lo] Error 1 I've configured with: $ ./configure --prefix=/usr --with-state-trackers=dri --disable-egl --with-gallium-drivers=nouveau --disable-gallium-llvm Finally, I just upgraded gcc to 4.8.1 (from 4.7.2), so this could be a compiler regression. -- You are receiving this mail because: You are the assignee for the bug.

1 3

← Newer
1
...
47
48
49
50
51
52
53
...
73
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2013