dri-devel November 2014

dri-devel@lists.freedesktop.org

182 participants
1119 discussions

[Bug 85950] [regression] Mesa 10.3.2 - radeon rv6xx GPU when using OpenGL games
by bugzilla-daemon＠freedesktop.org 10 Nov '14

10 Nov '14

https://bugs.freedesktop.org/show_bug.cgi?id=85950 --- Comment #4 from Michel Dänzer <michel(a)daenzer.net> --- If you don't tell us what version of Mesa you were running in the August-September time-frame, all we can do is resolve this report as fixed in Git master then. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm: add properties for suggested x/y offset for connectors. (v2)
by Dave Airlie 10 Nov '14

10 Nov '14

From: Dave Airlie <airlied(a)redhat.com> Virtual GPUs would like to give the guest some indication where on the screen the outputs are layed out. So far we only provide modes, these properties could be exposed to userspace so the desktop environment could use them as hints to set the correct offsets. v2: rename properties to be more consistent. Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- Documentation/DocBook/drm.tmpl | 17 ++++++++++++++++- drivers/gpu/drm/drm_crtc.c … [View More] | 24 ++++++++++++++++++++++++ include/drm/drm_crtc.h | 5 +++++ 3 files changed, 45 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 64d9c1e..e286458 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2533,7 +2533,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >Description/Restrictions</td> </tr> <tr> - <td rowspan="21" valign="top" >DRM</td> + <td rowspan="23" valign="top" >DRM</td> <td rowspan="2" valign="top" >Generic</td> <td valign="top" >“EDID”</td> <td valign="top" >BLOB | IMMUTABLE</td> @@ -2664,6 +2664,21 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> + <td rowspan="2" valign="top" >Virtual GPU</td> + <td valign="top" >“suggested X”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0xffffffff</td> + <td valign="top" >Connector</td> + <td valign="top" >property to suggest an X offset for a connector</td> + </tr> + <tr> + <td valign="top" >“suggested Y”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0xffffffff</td> + <td valign="top" >Connector</td> + <td valign="top" >property to suggest an Y offset for a connector</td> + </tr> + <tr> <td rowspan="3" valign="top" >Optional</td> <td valign="top" >“scaling mode”</td> <td valign="top" >ENUM</td> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 0f3c24c..22ca7c5 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1534,6 +1534,30 @@ int drm_mode_create_dirty_info_property(struct drm_device *dev) } EXPORT_SYMBOL(drm_mode_create_dirty_info_property); +/** + * drm_mode_create_suggested_offset_properties - create suggests offset properties + * @dev: DRM device + * + * Create the the suggested x/y offset property for connectors. + */ +int drm_mode_create_suggested_offset_properties(struct drm_device *dev) +{ + if (dev->mode_config.suggested_x_property && dev->mode_config.suggested_y_property) + return 0; + + dev->mode_config.suggested_x_property = + drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "suggested X", 0, 0xffffffff); + + dev->mode_config.suggested_y_property = + drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "suggested Y", 0, 0xffffffff); + + if (dev->mode_config.suggested_x_property == NULL || + dev->mode_config.suggested_y_property == NULL) + return -ENOMEM; + return 0; +} +EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties); + static int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group *group) { uint32_t total_objects = 0; diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index bc1cc3c..9d147fe 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -1036,6 +1036,10 @@ struct drm_mode_config { struct drm_property *aspect_ratio_property; struct drm_property *dirty_info_property; + /* properties for virtual machine layout */ + struct drm_property *suggested_x_property; + struct drm_property *suggested_y_property; + /* dumb ioctl parameters */ uint32_t preferred_depth, prefer_shadow; @@ -1228,6 +1232,7 @@ extern int drm_mode_create_tv_properties(struct drm_device *dev, int num_formats extern int drm_mode_create_scaling_mode_property(struct drm_device *dev); extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev); extern int drm_mode_create_dirty_info_property(struct drm_device *dev); +extern int drm_mode_create_suggested_offset_properties(struct drm_device *dev); extern int drm_mode_connector_attach_encoder(struct drm_connector *connector, struct drm_encoder *encoder); -- 1.9.3 [View Less]

1 0

[git pull] drm radeon and i915 fixes
by Dave Airlie 10 Nov '14

10 Nov '14

Hi Linus, I probably should have sent these earlier, but nothing too urgent in them, i915, blackscreen and corruption fixes radeon, oops, locking and stability. Dave. The following changes since commit ed78bb846e8bc1a8589fa6e0d9bf2b0f518893d5: Merge tag 'pci-v3.18-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci (2014-11-06 11:33:06 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to … [View More]

1 0

[PULL] topic/atomic-helpers
by Daniel Vetter 09 Nov '14

09 Nov '14

Hi Dave, So here's my atomic series, finally all debugged&reviewed. Sean Paul has done a full detailed pass over it all, and a lot of other people have commented and provided feedback on some parts. Rob Clark also converted msm over the w/e and seems happy. The only small thing is that Rob wants to export the wait_for_vblank, which imo makes sense. Since there's other stuff still to do I think we should apply Rob's patch (once it has grown appropriate kerneldoc) later on top of this. This … [View More]is just the core<->driver interface plus a big pile of helpers. Short recap of the main ideas: - There are essentially three helper libraries in this patch set: * Transitional helpers to use the new plane callbacks for legacy plane updates and in the crtc helper's ->mode_set callback. These helpers are only temporarily used to convert drivers to atomic, but they allow a nice separation between changing the driver backend and switching to the atomic commit logic. * Legacy helpers to implement all the legacy driver entry points (page_flip, set_config, plane vfuncs) on top of the new atomic driver interface. These are completely driver agnostic. The reason for having the legacy support as helpers is that drivers can switch step-by-step. And they could e.g. even keep the legacy page_flip code around for some old platforms where converting to full-blown atomic isn't worth it. * Atomic helpers which implement the various new ->atomic_* driver interfaces in terms of the revised crtc helper and new plane helper hooks. - The revised crtc helper implemenation essentially implements all the lessons learned in the i915 modeset rework (when using the atomic helpers only): * Enable/disable sequence for a given config are always the same and callbacks are always called in the same order. This contrast starkly with the crtc helpers, where the sequence of operations is heavily dependent on the previous config. One corollary of this is that if the configuration of a crtc only partially changes (e.g. a connector moves in a cloned config) the helper code will still disable/enable the full display pipeline. This is the only way to ensure that the enable/disable sequence is always the same. * It won't call disable or enable hooks more than once any more because it lost track of state, thanks to the atomic state tracking. And if drivers implement the ->reset hook properly (by either resetting the hw or reading out the hw state into the atomic structures) this even extends to the hardware state. So no more disable-me-harder kind of nonsense. * The only thing missing is the hw state readout/cross-check support, but if drivers have hw state readout support in their ->reset handlers it's simple to extend that to cross-check the hw state. * The crtc->mode_set callback is gone and its replacement only sets crtc timings and no longer updates the primary plane state. This way we can finally implement primary planes properly. - The new plane helpers should be suitable enough for pretty much everything, and a perfect fit for hardware with GO bits. Even if they don't fit the atomic helper library is rather flexible and exports all the functions for the individual steps to drivers. So drivers can pick what matches and implement their own magic for everything else. - A big difference compared to all previous atomic series is that this one doesn't implement async commit in a generic way. Imo driver requirements for that are too diverse to create anything reasonable sane which would actually work on a reasonable amount of different drivers. Also, we've never had a helper library for page_flips even, so it's really hard to know what might work and what's stupid without a bit of experience in the form of a few driver implementations. I think with the current flexibility for drivers to pick individual stages and existing helpers like drm_flip_queue it's rather easy though to implement proper async commit. - There's a few other differences of minor importance to earlier atomic series: * Common/generic properties are parsed in the callers/core and not in drivers, and passed to drivers by directly setting the right members in atomic state structures. That greatly simplifies all the transitional and legacy helpers an removes a lot of boilerplate code. * There's no crazy trylock mode used for the async commit since these helpers don't do async commit. A simple ordered flip queue of atomic state updates should be sufficient for preventing concurrent hw access anyway, as long as synchronous updates stall correctly with e.g. flush_work_queue or similar function. Abusing locks to enforce ordering isn't a good idea imo anyway. * These helpers reuse the existing ->mode_fixup hooks in the atomic_check callback. Which means that drivers need to adapat and move a lot less code into their atomic_check callbacks. Now this isn't everything needed in the drm core and helpers for full atomic support. But it's enough to start with converting drivers, and except for actually testing multiplane and multicrtc updates also enough to implement full atomic updates. Still missing are: - Per-plane locking. Since these helpers here encapsulate the locking completely this should be fairly easy to implement. - fbdev support for atomic_check/commit, so that multi-pipe finally works sanely in fbcon. - Adding and decoding shared/core properties. That just needs to be rebased from Rob's latest patch series, with minor adjustments so that the decoding happens in the core instead of in drivers. - Actually adding the atomic ioctl. Again just rebasing Rob's latest patch should be all that's needed. - Resolving how to deal with DPMS in atomic. Atomic is a good excuse to fix up the crazy semantics dpms currently has. I'm floating an RFC about this topic already. - Finally I couldn't test connector/encoder stealing properly since my test vehicle here doesn't allow a connector on different crtcs. So drivers which support this might see some surprises in that area. There is no semantic change though in how encoder stealing and assignment works (or at least no intended one), so I think the risk is minimal. As just mentioned I've done a fake conversion of an existing driver using crtc helpers to debug the helper code and validate the smooth transition approach. And that smooth transition was the really big motivation for this. It seems to actually work and consists of 3 phases: Phase 1: Rework driver backend for crtc/plane helpers The requirement here is that universal plane support is already implement. If universal plane support isn't implement yet it might be better though to just do it as part of this phase, directly using the new plane helpers. There are two big things to do: - Split up the existing ->update/disable_plane hooks into check/commit hooks and extract the crtc-wide prep/flush parts (like setting/clearing GO bits). - The other big change is to split the crtc->mode_set hook into the plane update (done using the plane helpers) and the crtc setup in a new ->mode_set_nofb hook. When phase 1 is complete the driver implements all the new callbacks which push the software state into hardware, but still using all the legacy entry points and crtc helpers. The transitional helpers serve as impendance mismatch here. Phase 2: Rework state handling This consists of rolling out the state handling helpers for planes, crtcs and connectors and reviewing all ->mode_fixup and similar hooks to make sure they don't depend upon implicit global state which might change in the atomic world. Any such code must be moved into ->atomic_check functions which just rely on the free-standing atomic state update structures. This phase also adds a few small pieces of fixup code to make sure the atomic state doesn't get out of sync in the legacy driver callbacks. Phase 3: Roll out atomic support Now it's just about replacing vfuncs with the ones provided by the helper and filling out the small missing pieces (like atomic_check logic or async commit support needed for page_flips). Due to the prep work in phase 1 no changes to the driver backend functions should be required, and because of the prep work in phase 2 atomic implementations can be rolled out step-by-step. So if async commit ins't implemented yet page_flip can be implemented with the legacy functions without wreaking havoc in the other operations. Cheers, Daniel The following changes since commit bbf0ef0334f2267687a92ec6d8114fd67b8157a3: Merge tag 'drm-intel-next-2014-10-03-no-ppgtt' of git://anongit.freedesktop.org/drm-intel into drm-next (2014-10-28 12:37:58 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/atomic-helpers-2014-11-09 for you to fetch changes up to 321ebf04dc7ab5c54d658f93db0ffe35277664ab: drm/atomic: Refcounting for plane_state->fb (2014-11-06 21:08:37 +0100) ---------------------------------------------------------------- Daniel Vetter (17): drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h drm: Pull drm_crtc.h into the kerneldoc template drm: fixup kerneldoc in drm_crtc.h drm/modeset_lock: document trylock_only in kerneldoc drm: Add atomic driver interface definitions for objects drm: Global atomic state handling drm: Add atomic/plane helpers drm/plane-helper: transitional atomic plane helpers drm/crtc-helper: Transitional functions using atomic plane helpers drm: Atomic crtc/connector updates using crtc/plane helper interfaces drm/atomic-helper: implementatations for legacy interfaces drm/atomic: Integrate fence support drm/atomic-helpers: document how to implement async commit drm/atomic-helper: implement ->page_flip drm/atomic-helpers: functions for state duplicate/destroy/reset drm: Docbook integration and over sections for all the new helpers drm/atomic: Refcounting for plane_state->fb Documentation/DocBook/drm.tmpl | 28 +- drivers/gpu/drm/Makefile | 4 +- drivers/gpu/drm/armada/armada_crtc.c | 1 + drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic.c | 628 +++++++++ drivers/gpu/drm/drm_atomic_helper.c | 1906 ++++++++++++++++++++++++++++ drivers/gpu/drm/drm_crtc_helper.c | 132 ++ drivers/gpu/drm/drm_plane_helper.c | 198 ++- drivers/gpu/drm/gma500/psb_intel_display.c | 1 + drivers/gpu/drm/mgag200/mgag200_mode.c | 1 + drivers/gpu/drm/nouveau/dispnv04/crtc.c | 1 + drivers/gpu/drm/nouveau/nv50_display.c | 1 + drivers/gpu/drm/omapdrm/omap_crtc.c | 1 + drivers/gpu/drm/qxl/qxl_display.c | 1 + drivers/gpu/drm/radeon/radeon_display.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 + drivers/gpu/drm/sti/sti_drm_crtc.c | 1 + drivers/gpu/drm/tegra/dc.c | 2 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 1 + drivers/gpu/drm/udl/udl_modeset.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 + drivers/staging/imx-drm/imx-drm-core.c | 1 + include/drm/drm_atomic.h | 67 + include/drm/drm_atomic_helper.h | 97 ++ include/drm/drm_crtc.h | 246 +++- include/drm/drm_crtc_helper.h | 13 + include/drm/drm_modeset_lock.h | 1 + include/drm/drm_plane_helper.h | 39 + 32 files changed, 3344 insertions(+), 36 deletions(-) create mode 100644 drivers/gpu/drm/drm_atomic.c create mode 100644 drivers/gpu/drm/drm_atomic_helper.c create mode 100644 include/drm/drm_atomic.h create mode 100644 include/drm/drm_atomic_helper.h -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch [View Less]

1 0

WARNING in intel_crtc_wait_for_pending_flips
by Mihai Donțu 08 Nov '14

08 Nov '14

Hi, A have a desktop and a laptop with Haswell and on both I'm experiencing this issue: after a time of continuous usage (days usually) I run into this warning: Nov 9 01:24:38 xyz kernel: ------------[ cut here ]------------ Nov 9 01:24:38 xyz kernel: WARNING: CPU: 2 PID: 10769 at drivers/gpu/drm/i915/intel_display.c:3361 intel_crtc_wait_for_pending_flips+0x174/0x180() Nov 9 01:24:38 xyz kernel: Modules linked in: vboxnetadp(O) vboxnetflt(O) vboxdrv(O) iwlmvm iwlwifi e1000e Nov 9 01:24:38 … [View More]xyz kernel: CPU: 2 PID: 10769 Comm: X Tainted: G W O 3.17.2-gentoo #2 Nov 9 01:24:38 xyz kernel: Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A09 05/01/2014 Nov 9 01:24:38 xyz kernel: 0000000000000009 ffff880403657c38 ffffffff96ca6904 0000000000000000 Nov 9 01:24:38 xyz kernel: ffff880403657c70 ffffffff96117dbd 0000000000000000 ffff8804083bc000 Nov 9 01:24:38 xyz kernel: ffff880407308150 ffff880407332000 ffff880407332000 ffff880403657c80 Nov 9 01:24:38 xyz kernel: Call Trace: Nov 9 01:24:38 xyz kernel: [<ffffffff96ca6904>] dump_stack+0x45/0x56 Nov 9 01:24:38 xyz kernel: [<ffffffff96117dbd>] warn_slowpath_common+0x7d/0xa0 Nov 9 01:24:38 xyz kernel: [<ffffffff96117e9a>] warn_slowpath_null+0x1a/0x20 Nov 9 01:24:38 xyz kernel: [<ffffffff966f4f04>] intel_crtc_wait_for_pending_flips+0x174/0x180 Nov 9 01:24:38 xyz kernel: [<ffffffff961511b0>] ? __wake_up_sync+0x20/0x20 Nov 9 01:24:38 xyz kernel: [<ffffffff966f4fb8>] intel_primary_plane_disable+0xa8/0xe0 Nov 9 01:24:38 xyz kernel: [<ffffffff9668e892>] setplane_internal+0x192/0x2b0 Nov 9 01:24:38 xyz kernel: [<ffffffff9668d089>] ? _object_find+0x69/0xa0 Nov 9 01:24:38 xyz kernel: [<ffffffff96691ed5>] drm_mode_setplane+0x145/0x1e0 Nov 9 01:24:38 xyz kernel: [<ffffffff966842cf>] drm_ioctl+0x1df/0x680 Nov 9 01:24:38 xyz kernel: [<ffffffff96245991>] ? new_sync_write+0x81/0xb0 Nov 9 01:24:38 xyz kernel: [<ffffffff962819ec>] ? fsnotify+0x27c/0x350 Nov 9 01:24:38 xyz kernel: [<ffffffff96258188>] do_vfs_ioctl+0x2c8/0x490 Nov 9 01:24:38 xyz kernel: [<ffffffff96248541>] ? __sb_end_write+0x31/0x60 Nov 9 01:24:38 xyz kernel: [<ffffffff96246132>] ? vfs_write+0x1c2/0x200 Nov 9 01:24:38 xyz kernel: [<ffffffff96258391>] SyS_ioctl+0x41/0x80 Nov 9 01:24:38 xyz kernel: [<ffffffff96caf052>] system_call_fastpath+0x16/0x1b Nov 9 01:24:38 xyz kernel: ---[ end trace e54582f8e99380e5 ]--- Nov 9 01:24:38 xyz kernel: [drm:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip Nov 9 01:24:38 xyz kernel: ------------[ cut here ]------------ Nov 9 01:24:38 xyz kernel: WARNING: CPU: 2 PID: 10769 at drivers/gpu/drm/i915/intel_display.c:1278 assert_plane.constprop.74+0x6b/0x70() Nov 9 01:24:38 xyz kernel: plane A assertion failure (expected on, current off) Nov 9 01:24:38 xyz kernel: Modules linked in: vboxnetadp(O) vboxnetflt(O) vboxdrv(O) iwlmvm iwlwifi e1000e Nov 9 01:24:38 xyz kernel: CPU: 2 PID: 10769 Comm: X Tainted: G W O 3.17.2-gentoo #2 Nov 9 01:24:38 xyz kernel: Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A09 05/01/2014 Nov 9 01:24:38 xyz kernel: 0000000000000009 ffff8804036577b0 ffffffff96ca6904 ffff8804036577f8 Nov 9 01:24:38 xyz kernel: ffff8804036577e8 ffffffff96117dbd 0000000000000000 ffff8804083bc000 Nov 9 01:24:38 xyz kernel: ffff880407332000 ffff880407300000 0000000000000000 ffff880403657848 Nov 9 01:24:38 xyz kernel: Call Trace: Nov 9 01:24:38 xyz kernel: [<ffffffff96ca6904>] dump_stack+0x45/0x56 Nov 9 01:24:38 xyz kernel: [<ffffffff96117dbd>] warn_slowpath_common+0x7d/0xa0 Nov 9 01:24:38 xyz kernel: [<ffffffff96117e2c>] warn_slowpath_fmt+0x4c/0x50 Nov 9 01:24:38 xyz kernel: [<ffffffff966f249b>] assert_plane.constprop.74+0x6b/0x70 Nov 9 01:24:38 xyz kernel: [<ffffffff966f5d11>] hsw_disable_ips+0x41/0x180 Nov 9 01:24:38 xyz kernel: [<ffffffff966fd219>] intel_crtc_disable_planes+0x49/0x160 Nov 9 01:24:38 xyz kernel: [<ffffffff966fe117>] haswell_crtc_disable+0x57/0x330 Nov 9 01:24:38 xyz kernel: [<ffffffff966f6992>] ? __intel_set_mode+0x52/0x16d0 Nov 9 01:24:38 xyz kernel: [<ffffffff966f6c08>] __intel_set_mode+0x2c8/0x16d0 Nov 9 01:24:38 xyz kernel: [<ffffffff9668767e>] ? drm_err+0x5e/0x60 Nov 9 01:24:38 xyz kernel: [<ffffffff966ff8f6>] intel_set_mode+0x16/0x30 Nov 9 01:24:38 xyz kernel: [<ffffffff96700a54>] intel_crtc_set_config+0xaf4/0xef0 Nov 9 01:24:38 xyz kernel: [<ffffffff9668e1e4>] drm_mode_set_config_internal+0x64/0xe0 Nov 9 01:24:38 xyz kernel: [<ffffffff9667c273>] restore_fbdev_mode+0xb3/0xe0 Nov 9 01:24:38 xyz kernel: [<ffffffff9667c2c3>] drm_fb_helper_restore_fbdev_mode_unlocked+0x23/0x40 Nov 9 01:24:38 xyz kernel: [<ffffffff9667e488>] drm_fb_helper_set_par+0x28/0x70 Nov 9 01:24:38 xyz kernel: [<ffffffff9670b6ba>] intel_fbdev_set_par+0x1a/0x60 Nov 9 01:24:38 xyz kernel: [<ffffffff966173f4>] fb_set_var+0x1a4/0x410 Nov 9 01:24:38 xyz kernel: [<ffffffff96146b19>] ? update_curr+0x79/0x190 Nov 9 01:24:38 xyz kernel: [<ffffffff96611246>] fbcon_blank+0x296/0x370 Nov 9 01:24:38 xyz kernel: [<ffffffff9613d64d>] ? ttwu_do_activate.constprop.92+0x5d/0x70 Nov 9 01:24:38 xyz kernel: [<ffffffff965f10aa>] do_unblank_screen+0xba/0x1f0 Nov 9 01:24:38 xyz kernel: [<ffffffff965e7179>] complete_change_console+0x59/0xe0 Nov 9 01:24:38 xyz kernel: [<ffffffff965e8390>] vt_ioctl+0x1190/0x1420 Nov 9 01:24:38 xyz kernel: [<ffffffff965dbd35>] tty_ioctl+0x285/0xbc0 Nov 9 01:24:38 xyz kernel: [<ffffffff96245991>] ? new_sync_write+0x81/0xb0 Nov 9 01:24:38 xyz kernel: [<ffffffff962819ec>] ? fsnotify+0x27c/0x350 Nov 9 01:24:38 xyz kernel: [<ffffffff96258188>] do_vfs_ioctl+0x2c8/0x490 Nov 9 01:24:38 xyz kernel: [<ffffffff96248541>] ? __sb_end_write+0x31/0x60 Nov 9 01:24:38 xyz kernel: [<ffffffff96258391>] SyS_ioctl+0x41/0x80 Nov 9 01:24:38 xyz kernel: [<ffffffff96caf052>] system_call_fastpath+0x16/0x1b Nov 9 01:24:38 xyz kernel: ---[ end trace e54582f8e99380e6 ]--- X stop rendering but I can still move the mouse. If I press ctrl+alt+1, after 15-20s I'm presented with the console and I can do: # service xdm restart and get back to normal. The issue will reappear and it will be cured the same way. I've seen this before on a Sandy Bridge as well: http://lists.freedesktop.org/archives/dri-devel/2014-August/065689.html but setting 'drm.debug=0xe' has somehow hidden it and couldn't provide any more information. Desktop: 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset Family KT Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 04) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4) 00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #2 (rev d4) 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04) 02:00.0 PCI bridge: Texas Instruments XIO2001 PCI Express-to-PCI Bridge 03:02.0 Network controller: Qualcomm Atheros AR9227 Wireless Network Adapter (rev 01) Laptop: 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b) 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) 00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b) 00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04) 00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04) 00:16.3 Serial controller: Intel Corporation 8 Series HECI KT (rev 04) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04) 00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4) 00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4) 00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04) 02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73) Thanks, -- Mihai Donțu [View Less]

1 0

[Bug 85950] [regression] Mesa 10.3.2 - radeon rv6xx GPU when using OpenGL games
by bugzilla-daemon＠freedesktop.org 08 Nov '14

08 Nov '14

https://bugs.freedesktop.org/show_bug.cgi?id=85950 Shawn Starr <shawn.starr(a)rogers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|GLAMOR crashes w/ radeon |[regression] Mesa 10.3.2 - |rv6xx GPU when using OpenGL |radeon rv6xx GPU when using |games |OpenGL games -- You are receiving this mail because: You … [View More]

1 0

[Bug 85950] GLAMOR crashes w/ radeon rv6xx GPU when using OpenGL games
by bugzilla-daemon＠freedesktop.org 08 Nov '14

08 Nov '14

https://bugs.freedesktop.org/show_bug.cgi?id=85950 --- Comment #3 from Shawn Starr <shawn.starr(a)rogers.com> --- Yes it is indeed Mesa. The last stable Mesa I had tested was: mesa-dri-drivers-10.4-0.devel.2.1.20140907.fc21.x86_64.rpm Compiled from git master but used the .spec file to build it properly. Assuming from Sept 9th to now nothing broke in 10.4.x I should be ok going to git master. However, 10.3.x is unstable for rv6xx. -- You are receiving this mail because: You are the … [View More]

1 0

[PATCH V2 0/2] make imx hdmi publicly used by dw hdmi compatible platform
by Andy Yan 08 Nov '14

08 Nov '14

We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly difference, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only access by word), 4K support(imx6 doesn't support 4k, but rk3288 does). To reuse the imx-hdmi driver, we do this patch set: patch (1): split out imx-soc code from imx-hdmi to dw_hdmi-imx.c patch (2): move imx-… [View More]

4 19

[PATCH] drm/i915: avoid deadlock on failure paths in __intel_framebuffer_create()
by Alexey Khoroshilov 07 Nov '14

07 Nov '14

Since a8bb6818270c __intel_framebuffer_create() is called with struct_mutex held, so it should use drm_gem_object_unreference() instead of drm_gem_object_unreference_unlocked(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru> --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c … [View More]

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 07 Nov '14

07 Nov '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #50 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to Alex Deucher from comment #49) > (In reply to Anton L. from comment #48) > > Alex, will these patches correct fan speed for PITCAIRN cards? > > Yes, once they are working properly. Oh, thanks, Alex, I'll try to figure out what needs to be done on weekend -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2014