dri-devel February 2013

dri-devel@lists.freedesktop.org

130 participants
696 discussions

Re: kernel BUG at mm/slub.c:3409, 3.8.0-rc7
by Peter Hurley 19 Feb '13

19 Feb '13

[+cc Marcin Slusarz, dri-devel] On Tue, 2013-02-19 at 00:21 +0000, Christoph Lameter wrote: > The problem is that the subsystem attempted to call kfree with a pointer > that was not obtained via a slab allocation. > > On Sat, 16 Feb 2013, Denys Fedoryshchenko wrote: > > > Hi > > > > Worked for a while on 3.8.0-rc7, generally it is fine, then suddenly laptop > > stopped responding to keyboard and mouse. > > Sure it can be memory corruption by some other module, but maybe not. Worth to > > report i guess. > > After reboot checked logs and found this: > > > > Feb 16 00:40:17 localhost kernel: [23260.079253] ------------[ cut here > > ]------------ > > Feb 16 00:40:17 localhost kernel: [23260.079257] kernel BUG at mm/slub.c:3409! > > Feb 16 00:40:17 localhost kernel: [23260.079259] invalid opcode: 0000 [#1] SMP > > Feb 16 00:40:17 localhost kernel: [23260.079262] Modules linked in: > > ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 > > xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter > > ip_tables tun bridge stp llc nouveau snd_hda_codec_hdmi coretemp kvm_intel Was there an allocation failure earlier in the log? Might be this nouveau bug (linux-next at the time was 3.8 now): https://bugs.freedesktop.org/show_bug.cgi?id=58087 I think this was fixed but neither bug report has a cross reference :( The original report is here: https://bugzilla.kernel.org/show_bug.cgi?id=51291 Pekka, Can you please re-assign the bugzilla #51291 above to DRI? Thanks. Regards, Peter Hurley

1 0

[pull] tilcdc-next for 3.9
by Rob Clark 18 Feb '13

18 Feb '13

Hi Dave, Here is pull request for tilcdc drm driver.. it also includes a handful of dependent patches from me, plus a couple fixes from Daniel Vetter which haven't showed up yet in drm-next. ---------- The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2: Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15 10:22:01 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux tilcdc-next for you to fetch changes up to 073c917bd87a016012e03c8d98301192ae22ae34: drm/tilcdc: add support for LCD panels (v5) (2013-02-17 17:55:44 -0500) ---------------------------------------------------------------- Daniel Vetter (2): drm/cma-helper: fixup compilation drm: Don't set the plane->fb to NULL on successfull set_plane Rob Clark (8): drm: small fix in drm_send_vblank_event() drm/cma: add debugfs helpers drm: i2c encoder helper wrappers drm/nouveau: use i2c encoder helper wrappers drm/tilcdc: add TI LCD Controller DRM driver (v4) drm/i2c: nxp-tda998x (v3) drm/tilcdc: add encoder slave (v2) drm/tilcdc: add support for LCD panels (v5) .../devicetree/bindings/drm/tilcdc/panel.txt | 59 ++ .../devicetree/bindings/drm/tilcdc/slave.txt | 19 + .../devicetree/bindings/drm/tilcdc/tfp410.txt | 21 + .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 21 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_crtc.c | 2 +- drivers/gpu/drm/drm_encoder_slave.c | 63 ++ drivers/gpu/drm/drm_fb_cma_helper.c | 55 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 21 + drivers/gpu/drm/drm_irq.c | 1 + drivers/gpu/drm/i2c/Kconfig | 6 + drivers/gpu/drm/i2c/Makefile | 3 + drivers/gpu/drm/i2c/tda998x_drv.c | 906 +++++++++++++++++++++ drivers/gpu/drm/nouveau/nv04_tv.c | 39 +- drivers/gpu/drm/tilcdc/Kconfig | 13 + drivers/gpu/drm/tilcdc/Makefile | 10 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 602 ++++++++++++++ drivers/gpu/drm/tilcdc/tilcdc_drv.c | 611 ++++++++++++++ drivers/gpu/drm/tilcdc/tilcdc_drv.h | 150 ++++ drivers/gpu/drm/tilcdc/tilcdc_panel.c | 436 ++++++++++ drivers/gpu/drm/tilcdc/tilcdc_panel.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_regs.h | 154 ++++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 376 +++++++++ drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 419 ++++++++++ drivers/gpu/drm/tilcdc/tilcdc_tfp410.h | 26 + include/drm/drm_encoder_slave.h | 20 + include/drm/drm_fb_cma_helper.h | 5 + include/drm/drm_gem_cma_helper.h | 4 + 30 files changed, 4070 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c create mode 100644 drivers/gpu/drm/tilcdc/Kconfig create mode 100644 drivers/gpu/drm/tilcdc/Makefile create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h

3 10

[PATCH] intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
by Daniel Vetter 18 Feb '13

18 Feb '13

We already have the quirk entry for the mobile platform, but also reports on some desktop versions. So be paranoid and set it everywhere. References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html Cc: stable(a)vger.kernel.org Cc: David Woodhouse <dwmw2(a)infradead.org> Reported-and-tested-by: Mihai Moldovan <ionic(a)ionic.de> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/iommu/intel-iommu.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 9743769..19854bf 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4215,13 +4215,19 @@ static void __devinit quirk_iommu_rwbf(struct pci_dev *dev) { /* * Mobile 4 Series Chipset neglects to set RWBF capability, - * but needs it: + * but needs it. Same seems to hold for the desktop versions. */ printk(KERN_INFO "DMAR: Forcing write-buffer flush capability\n"); rwbf_quirk = 1; } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_rwbf); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_rwbf); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_rwbf); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_rwbf); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_rwbf); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_rwbf); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_rwbf); #define GGC 0x52 #define GGC_MEMORY_SIZE_MASK (0xf << 8) -- 1.7.10.4

3 3

[PATCH] omapdrm: Make fixed resolution panels work
by Archit Taneja 18 Feb '13

18 Feb '13

The omapdrm driver requires omapdss panel drivers to expose ops like detect, set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI and SDI drivers. At some places, there are no checks to see if the panel driver has these ops or not, and that leads to a crash. The following things are done to make fixed panels work: - The omap_connector's detect function is modified such that it considers panel types which are generally fixed panels as always connected(provided the panel driver doesn't have a detect op). Hence, the connector corresponding to these panels is always in a 'connected' state. - If a panel driver doesn't have a check_timings op, assume that it supports the mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function) - The function omap_encoder_update shouldn't really do anything for fixed resolution panels, make sure that it calls set_timings only if the panel driver has one. I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other working boards with fixed DPI panels. I could try the DSI video mode panel on an OMAP5 sevm, but that will require me to patch a lot of things to get omap5 dss work with DT. I can try if needed. Signed-off-by: Archit Taneja <archit(a)ti.com> --- drivers/staging/omapdrm/omap_connector.c | 10 ++++++++-- drivers/staging/omapdrm/omap_encoder.c | 6 ++++-- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c index 4cc9ee7..839c6e4 100644 --- a/drivers/staging/omapdrm/omap_connector.c +++ b/drivers/staging/omapdrm/omap_connector.c @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect( ret = connector_status_connected; else ret = connector_status_disconnected; + } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI || + dssdev->type == OMAP_DISPLAY_TYPE_DBI || + dssdev->type == OMAP_DISPLAY_TYPE_SDI || + dssdev->type == OMAP_DISPLAY_TYPE_DSI) { + ret = connector_status_connected; } else { ret = connector_status_unknown; } @@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct drm_connector *connector, struct omap_video_timings timings = {0}; struct drm_device *dev = connector->dev; struct drm_display_mode *new_mode; - int ret = MODE_BAD; + int r, ret = MODE_BAD; copy_timings_drm_to_omap(&timings, mode); mode->vrefresh = drm_mode_vrefresh(mode); - if (!dssdrv->check_timings(dssdev, &timings)) { + r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) : 0; + if (!r) { /* check if vrefresh is still valid */ new_mode = drm_mode_duplicate(dev, mode); new_mode->clock = timings.pixel_clock; diff --git a/drivers/staging/omapdrm/omap_encoder.c b/drivers/staging/omapdrm/omap_encoder.c index e053160..871af12e 100644 --- a/drivers/staging/omapdrm/omap_encoder.c +++ b/drivers/staging/omapdrm/omap_encoder.c @@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder, dssdev->output->manager = mgr; - ret = dssdrv->check_timings(dssdev, timings); + ret = dssdrv->check_timings ? + dssdrv->check_timings(dssdev, timings) : 0; if (ret) { dev_err(dev->dev, "could not set timings: %d\n", ret); return ret; } - dssdrv->set_timings(dssdev, timings); + if (dssdrv->set_timings) + dssdrv->set_timings(dssdev, timings); return 0; } -- 1.7.9.5

3 4

[GMA500] Valid VCO frequency range on GMA500 platform?
by "David Müller (ELSOFT AG)" 18 Feb '13

18 Feb '13

Hello I have a problem using a 1024x768 Eizo Monitor attached by DVI-D to a system with GMA500 based graphics and running under Linux-3.7. As soon as the GMA500 driver is taking over control, the refresh rate raises to 64.5Hz and the monitor reports a "signal error". For me i looks like the GMA500 driver is reprogramming the VCO to a too high dot clock. If i lower the "I9XX_VCO_MIN" value to 1300000, everything is fine. Is the "I9XX_VCO_MIN" value used in the GMA500 driver correct? Dave

2 5

[PATCH v3 0/7] drm/tegra: Miscellaneous enhancements
by Thierry Reding 18 Feb '13

18 Feb '13

This patch series introduces a number of useful features for the Tegra DRM driver. Patch 1 is a documentation update and adds a warning to the page-flip IOCTL to catch buggy drivers that return success but failed to update the crtc->fb field, which would cause the reference counting to become unbalanced. Patch 2 adds support for the additional two planes available on Tegra hardware, while patch 3 implement .mode_set_base() to allow for some nice speed up when changing the framebuffer without actually changing the resolution. Patch 4 adds VBLANK support and patch 5 builds on the previous two to provide the page-flipping IOCTL. Patch 6 splits the DC_CMD_STATE_CONTROL register writes into two consecutive writes as required by the TRM. Finally patch 7 adds a new file, named "framebuffers" to debugfs which can be used to dump a list of framebuffers attached to the DRM device. This is most useful to inspect the reference count but could also be helpful in diagnosing out-of-memory conditions and such. Thierry Thierry Reding (7): drm: Add consistency check for page-flipping drm/tegra: Add plane support drm/tegra: Implement .mode_set_base() drm/tegra: Implement VBLANK support drm/tegra: Implement page-flipping support drm/tegra: Split DC_CMD_STATE_CONTROL register write drm/tegra: Add list of framebuffers to debugfs Documentation/DocBook/drm.tmpl | 6 + drivers/gpu/drm/drm_crtc.c | 7 + drivers/gpu/drm/tegra/dc.c | 489 ++++++++++++++++++++++++++++++++--------- drivers/gpu/drm/tegra/dc.h | 2 +- drivers/gpu/drm/tegra/drm.c | 103 +++++++++ drivers/gpu/drm/tegra/drm.h | 37 ++++ 6 files changed, 533 insertions(+), 111 deletions(-) -- 1.8.1.2

3 22

[pull] omapdrm-next for 3.9
by Rob Clark 17 Feb '13

17 Feb '13

Hi Dave, This pull moves omapdrm out of staging into drivers/gpu/drm.. since there are a couple patches already in staging-next, I cherry-picked these onto omapdrm-next (which is based on drm-next rather than staging-next). I've also added a couple of Daniel's omapdrm patches, fixed up to apply in drivers/gpu/drm. ---------- The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2: Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15 10:22:01 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux omapdrm-next for you to fetch changes up to 8e44770f093c003d11784060fea4ffc82ad576eb: drm/omap: remove fbdev debug enter/leave hooks (2013-02-16 18:14:04 -0500) ---------------------------------------------------------------- Andy Gross (2): drm/omap: Add PM capabilities drm/omap: Add OMAP5 support Cong Ding (1): staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage Daniel Vetter (2): omapdrm: only take crtc->mutex in crtc callbacks omapdrm: simplify locking in the fb debugfs file Peter Huewe (1): staging/omapdrm: Use kmemdup rather than duplicating its implementation Rob Clark (2): drm/omap: move out of staging drm/omap: remove fbdev debug enter/leave hooks drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/{staging => gpu/drm}/omapdrm/Kconfig | 0 drivers/{staging => gpu/drm}/omapdrm/Makefile | 0 drivers/gpu/drm/omapdrm/TODO | 23 +++ .../{staging => gpu/drm}/omapdrm/omap_connector.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c | 14 +- .../{staging => gpu/drm}/omapdrm/omap_debugfs.c | 16 +-- .../{staging => gpu/drm}/omapdrm/omap_dmm_priv.h | 5 + .../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c | 159 +++++++++++++++------ .../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h | 0 drivers/{staging => gpu/drm}/omapdrm/omap_drv.c | 16 ++- drivers/{staging => gpu/drm}/omapdrm/omap_drv.h | 8 +- .../{staging => gpu/drm}/omapdrm/omap_encoder.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_fb.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c | 5 +- drivers/{staging => gpu/drm}/omapdrm/omap_gem.c | 34 ++++- .../{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c | 8 +- .../drm}/omapdrm/omap_gem_helpers.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_irq.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_plane.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c | 0 drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h | 0 drivers/{staging => gpu/drm}/omapdrm/tcm.h | 2 + drivers/staging/Kconfig | 2 - drivers/staging/Makefile | 1 - drivers/staging/omapdrm/TODO | 32 ----- .../omapdrm => include/uapi/drm}/omap_drm.h | 2 +- 28 files changed, 220 insertions(+), 122 deletions(-) rename drivers/{staging => gpu/drm}/omapdrm/Kconfig (100%) rename drivers/{staging => gpu/drm}/omapdrm/Makefile (100%) create mode 100644 drivers/gpu/drm/omapdrm/TODO rename drivers/{staging => gpu/drm}/omapdrm/omap_connector.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_debugfs.c (90%) rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_priv.h (96%) rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c (86%) rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h (100%) rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.c (97%) rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.h (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_encoder.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_fb.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_gem.c (97%) rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_helpers.c (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_irq.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_plane.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c (100%) rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h (100%) rename drivers/{staging => gpu/drm}/omapdrm/tcm.h (99%) delete mode 100644 drivers/staging/omapdrm/TODO rename {drivers/staging/omapdrm => include/uapi/drm}/omap_drm.h (99%)

1 0

Re: Debugging Thinkpad T430s occasional suspend failure.
by Linus Torvalds 17 Feb '13

17 Feb '13

On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins <hughd(a)google.com> wrote: > > I hacked around on your PM_TRACE set_magic_time() / read_magic_time() > yesterday, to save an oopsing core kernel ip there, instead of hashed > pm trace info (it makes sense in this case to invert your sequence, > putting the high order into years and the low order into minutes). That sounds like a good idea in general. The PM_TRACE() thing was done to figure out things that locked up the PCI bus etc, but encoding the oopses during suspend sounds like a really good idea too. Is your patch clean enough to just be made part of the standard PM_TRACE infrastructure, or was it something really hacky and one-off? > Rewarded last night by reboot to Feb 21 14:45:53 2006. Which is > ffffffff812d60ed intel_choose_pipe_bpp_dither.isra.13+0x216/0x2d6 > > /home/hugh/3087X/drivers/gpu/drm/i915/intel_display.c:4159 > * enable dithering as needed, but that costs bandwidth. So choose > * the minimum value that expresses the full color range of the fb but > * also stays within the max display bpc discovered above. > */ > > switch (fb->depth) { > ffffffff812d60e9: 48 8b 55 c0 mov -0x40(%rbp),%rdx > ffffffff812d60ed: 8b 02 mov (%rdx),%eax > > (gcc chose to pass a pointer to fb->depth down to the function, > instead of fb itself, since that is the only use of it there.) > > I expect that fb is NULL; but with an average of one failure to resume > per day, and ~26 bits of info per crash, this is not a fast procedure! > > I notice that intel_pipe_set_base() allows for NULL fb, > so I'm currently running with the oops-in-rtc hackery, plus > - switch (fb->depth) { > + if (WARN_ON(!fb)) > + bpc = 8; > + else switch (fb->depth) { > > There's been a fair bit of change to intel_display.c since 3.7 (if > my 3.7 was indeed good), mainly splitting intel_ into haswell_ versus > ironlake_, but I've not yet spotted anything obvious; nor yet looked > to see where fb would originate from anyway. > > Once I've got just a little more info out of it, I'll start another > thread addressed principally to the drm/gpu/i915 guys. I think it's worth it to give them a heads-up already. So I've cc'd the main suspects here.. Daniel, Dave - any comments about a NULL fb in intel_choose_pipe_bpp_dither() during either suspend or resume? Some googling shows this: https://bugzilla.redhat.com/show_bug.cgi?id=895123 which sounds remarkably similar, and is also during a suspend attempt (but apparently Satish got a full oops out).. Some timing race with a worker entry? Linus

3 6

[Bug 60981] New: dri/r600: severe screen corruption with Radeon HD 6570
by bugzilla-daemon＠freedesktop.org 17 Feb '13

17 Feb '13

https://bugs.freedesktop.org/show_bug.cgi?id=60981 Priority: medium Bug ID: 60981 Assignee: dri-devel(a)lists.freedesktop.org Summary: dri/r600: severe screen corruption with Radeon HD 6570 Severity: major Classification: Unclassified OS: Linux (All) Reporter: steve(a)steve-m.de Hardware: Other Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Created attachment 74957 --> https://bugs.freedesktop.org/attachment.cgi?id=74957&action=edit lspci, xorg log and glxinfo With my VTX3D Radeon HD 6570 card the entire screen content is corrupted, see the images and video. The proprietary AMD driver works fine. This problem is nothing new, I've seen it since I got the card with Ubuntu 12.04, 12.10 and now 13.04 (+xorg-edgers-ppa). http://steve-m.de/pics/radeon_artifacts.png http://steve-m.de/pics/radeon_corruption.ogv Also see the attached logfiles. -- You are receiving this mail because: You are the assignee for the bug.

1 1

webgl-conformance-tests gives errors in drm module
by Toralf Förster 17 Feb '13

17 Feb '13

While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915 graphic. The kernel log gives: 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for forcewake to ack request. 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] *ERROR* GT thread status wait timed out 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get] *ERROR* Timed out waiting for forcewake to ack request. 2013-02-17T10:32:58.470+01:00 n22 kernel: [drm:__gen6_gt_wait_for_thread_c0] *ERROR* GT thread status wait timed out A developer responded of that bug report [2] that it is a MESA thing but b/c of the kernel msg I'm wondering whether the kernel module might be affected too ? [1] https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.ht… [2] https://bugzilla.mozilla.org/show_bug.cgi?id=814964 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

2 1

← Newer
1
...
53
54
55
56
57
58
59
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2013