Re: Bug report: i915 screens stay blank with 3.8.3, ok with 3.8.2
Daniel Vetter writes: > On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote: >> >> Moin, >> >> [1.] One line summary of the problem: >> >>Both screens stay blank during boot with 3.8.3. This has been fixed in 3.8.4. Sorry for the noise. >> [2.] Full description of the problem/report: >> >>When booting the screens go blank soon after showing the grub menu. >>Starting X11 does not bring the screens up either. >>In /var/log/dmesg two lines appear (diff -u): >> >> @@ -432,8 +434,10 @@ >> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). >> [drm] Driver supports precise vblank timestamp query. >> vgaarb: device changed decodes: >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem >> +i915 :00:02.0: No connectors reported connected with modes >> +[drm] Cannot find any crtc or sizes - going 1024x768 >> fbcon: inteldrmfb (fb0) is primary device >> -Console: switching to colour frame buffer device 240x75 >> +Console: switching to colour frame buffer device 128x48 >> i915 :00:02.0: fb0: inteldrmfb frame buffer device >> i915 :00:02.0: registered panic notifier >> i915: No ACPI video bus found > > Can you please file a bug report against bugs.freedesktop.org. They require to create an account, and I resolved to not open accounts anywhere just to file bug reports, sorry. > Please boot both broken and working kernel with drm.debug=0xe added to > your kernel cmdline and attach the complete dmesg of each to the bug > report. > > If you can do a quick bisect to figure out the offending commit, that > would be good, too. And can you please also check whether the latest > 3.9-rc kernel is affect? We need to know that since stable rules mandate > that regressions in stable kernels can only be fixed once upstream is > known to work. > > Thanks, Daniel -- Dr. Stephan Böttcher Tel: +49-431-880-2508 Christian-Albrechts-Universität zu Kiel Inst. f. Exp. u. Angew. Physik, Abt. Extraterrestrische Physik Leibnizstr. 11, 24118 Kiel, Germany ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 10:35 AM, Lijo Antony wrote: I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git bisect in that mail is incorrect). While investigating, I found this issue was introduced during 3.9 merge window. For me this comes when I connect my TV via HDMI. FWIW, git bisect gave this log, git bisect start 'drivers/gpu/' # good: [e450fcc6669705ef49784080ac6dd8513df37763] drm/tegra: Add list of framebuffers to debugfs git bisect good e450fcc6669705ef49784080ac6dd8513df37763 # bad: [6dbe51c251a327e012439c4772097a13df43c5b8] Linux 3.9-rc1 git bisect bad 6dbe51c251a327e012439c4772097a13df43c5b8 # good: [bab588fcfb6335c767d811a8955979f5440328e0] Merge tag 'soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good bab588fcfb6335c767d811a8955979f5440328e0 # good: [be88298b0a3f771a4802f20c5e66af74bfd1dff1] drm/tilcdc: only build on arm git bisect good be88298b0a3f771a4802f20c5e66af74bfd1dff1 # bad: [4d53233a36fdda567cd4d080e27e1ee4b669ddd1] drm: don't use idr_remove_all() git bisect bad 4d53233a36fdda567cd4d080e27e1ee4b669ddd1 # good: [9afa3195b96da7d2320ec44d19fbfbded7a15571] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial git bisect good 9afa3195b96da7d2320ec44d19fbfbded7a15571 # good: [496ad9aa8ef448058e36ca7a787c61f2e63f0f54] new helper: file_inode(file) git bisect good 496ad9aa8ef448058e36ca7a787c61f2e63f0f54 # bad: [d895cb1af15c04c522a25c79cc429076987c089b] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad d895cb1af15c04c522a25c79cc429076987c089b # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb -lijo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos: enable FIMD clocks
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patch also replaces clk_disable() with clk_disable_unprepare()
during exit.
Signed-off-by: Vikas Sajjan
---
Changes since v1:
- added error checking for clk_prepare_enable() and also replaced
clk_disable() with clk_disable_unprepare() during exit.
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..014d750 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -934,6 +934,19 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}
+ ret = clk_prepare_enable(ctx->lcd_clk);
+ if (ret) {
+ dev_err(dev, "failed to enable 'sclk_fimd' clock\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->bus_clk);
+ if (ret) {
+ clk_disable_unprepare(ctx->lcd_clk);
+ dev_err(dev, "failed to enable 'fimd' clock\n");
+ return ret;
+ }
+
ctx->vidcon0 = pdata->vidcon0;
ctx->vidcon1 = pdata->vidcon1;
ctx->default_win = pdata->default_win;
@@ -981,8 +994,8 @@ static int fimd_remove(struct platform_device *pdev)
if (ctx->suspended)
goto out;
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
pm_runtime_set_suspended(dev);
pm_runtime_put_sync(dev);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 12:40 AM, Peter Hurley wrote: with the hope of having the right people on CC now (finally, thanks Lucas :-)), here's the same splat on -rc3. Someone better take a look soonish, please: Also happens in next (on nv50 hardware). I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git bisect in that mail is incorrect). While investigating, I found this issue was introduced during 3.9 merge window. For me this comes when I connect my TV via HDMI. But for a couple of tags during bisecting, I have seen the same during boot also. -lijo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Bug report: i915 screens stay blank with 3.8.3, ok with 3.8.2
Daniel Vetter writes: > On Sat, Mar 16, 2013 at 01:04:34PM +0100, Stephan Boettcher wrote: >> >> Moin, >> >> [1.] One line summary of the problem: >> >>Both screens stay blank during boot with 3.8.3. This has been fixed in 3.8.4. Sorry for the noise. >> [2.] Full description of the problem/report: >> >>When booting the screens go blank soon after showing the grub menu. >>Starting X11 does not bring the screens up either. >>In /var/log/dmesg two lines appear (diff -u): >> >> @@ -432,8 +434,10 @@ >> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). >> [drm] Driver supports precise vblank timestamp query. >> vgaarb: device changed decodes: >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem >> +i915 :00:02.0: No connectors reported connected with modes >> +[drm] Cannot find any crtc or sizes - going 1024x768 >> fbcon: inteldrmfb (fb0) is primary device >> -Console: switching to colour frame buffer device 240x75 >> +Console: switching to colour frame buffer device 128x48 >> i915 :00:02.0: fb0: inteldrmfb frame buffer device >> i915 :00:02.0: registered panic notifier >> i915: No ACPI video bus found > > Can you please file a bug report against bugs.freedesktop.org. They require to create an account, and I resolved to not open accounts anywhere just to file bug reports, sorry. > Please boot both broken and working kernel with drm.debug=0xe added to > your kernel cmdline and attach the complete dmesg of each to the bug > report. > > If you can do a quick bisect to figure out the offending commit, that > would be good, too. And can you please also check whether the latest > 3.9-rc kernel is affect? We need to know that since stable rules mandate > that regressions in stable kernels can only be fixed once upstream is > known to work. > > Thanks, Daniel -- Dr. Stephan B?ttcher Tel: +49-431-880-2508 Christian-Albrechts-Universit?t zu Kiel Inst. f. Exp. u. Angew. Physik, Abt. Extraterrestrische Physik Leibnizstr. 11, 24118 Kiel, Germany
[Bug 10642] via DRM Unimplemented DMA HEADER command (HALCYON_CMDB)
https://bugs.freedesktop.org/show_bug.cgi?id=10642 James Simmons changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from James Simmons --- Mesa is not supported at this time. -- 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/20130320/e409728d/attachment.html>
[Bug 62578] r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
https://bugs.freedesktop.org/show_bug.cgi?id=62578 --- Comment #2 from Orion Poplawski --- The problem is also present in mesa 9.0.3. With that I also get the following in dmesg: Mar 20 13:51:28 aspen kernel: [162904.454217] [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer ! Mar 20 13:51:28 aspen kernel: [162904.454224] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! But I don't seem to get that with 9.1. -- 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/20130320/e7e2beaf/attachment.html>
[Bug 62578] r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
https://bugs.freedesktop.org/show_bug.cgi?id=62578 --- Comment #1 from Orion Poplawski --- Downgrading from llvm-libs-3.2-2.fc18 and mesa 9.1-1.fc18 to llvm-libs-3.1-11.fc18 and mesa 9.0.1-1.fc18 appears to fix the issue. -- 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/20130320/7d2008f6/attachment.html>
[Bug 62577] [r600g] GPU lockup when playing WoW with HD6450 without htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=62577 --- Comment #1 from Alex Deucher --- Is this a regression? if so can you bisect? -- 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/20130320/6bf78733/attachment.html>
[Bug 62578] New: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
https://bugs.freedesktop.org/show_bug.cgi?id=62578 Priority: medium Bug ID: 62578 Assignee: dri-devel at lists.freedesktop.org Summary: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state! Severity: major Classification: Unclassified OS: All Reporter: orion at cora.nwra.com Hardware: x86 (IA32) Status: NEW Version: 9.1 Component: Drivers/DRI/r300 Product: Mesa Created attachment 76846 --> https://bugs.freedesktop.org/attachment.cgi?id=76846&action=edit Xorg.0.log Running KDE 4.10.1 on Fedora 18. After login, screen flickers a bit but nothing is displayed other than the background image. .xsession-errors contains: OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV370 OpenGL version string: 2.1 Mesa 9.1 OpenGL shading language version string: 1.20 Driver: R300G GPU class: R300 OpenGL version: 2.1 GLSL version: 1.20 Mesa version: 9.1 Linux kernel version: 3.8.3 Direct rendering: yes Requires strict binding:yes GLSL shaders: limited Texture NPOT support: limited Virtual Machine:no r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state! this r300 messages keeps repeating. kernel 3.8.3-203.fc18.i686.PAE 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)] Just updated from Fedora 16 where this system was working fine. -- 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/20130320/039ebd78/attachment.html>
[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black
https://bugs.freedesktop.org/show_bug.cgi?id=60503 --- Comment #13 from Pavel Ondra?ka --- BTW i did a quick tests piglit run with your patch on my RV530 with no regressions (no fixes either except 2 tests in EXT_framebuffer_multisample group, however those seems to be fairly random... ) -- 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/20130320/92e3c585/attachment.html>
[Bug 62577] New: [r600g] GPU lockup when playing WoW with HD6450 without htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=62577 Priority: medium Bug ID: 62577 Assignee: dri-devel at lists.freedesktop.org Summary: [r600g] GPU lockup when playing WoW with HD6450 without htile enabled Severity: normal Classification: Unclassified OS: Linux (All) Reporter: rankincj at googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 76845 --> https://bugs.freedesktop.org/attachment.cgi?id=76845&action=edit dmesg output showing GPU lockup Just tried to play WoW against Mesa git, having already set R600_HYPERZ=0 to work around bug #61747. This resulted in a GPU lockup after a few minutes. git HEAD is: commit d24819dce8cf6dac23f27df46fabbf756a732229 Author: Kenneth Graunke Date: Mon Mar 11 11:10:34 2013 -0700 i965/vs: Add IR dumping for immediates. This makes dump_instructions more useful. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt -- 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/20130320/ac8e506b/attachment-0001.html>
[git pull] drm fixes
Hi Linus, radeon, intel and nouveau, along with one mgag200 fix, intel fix for an ioctl overflow, along with a regression fix for some phantom irqs on Ironlake. nouveau has a lockdep warning and a bunch of thermal fixes radeon has new pci ids and some minor fixes. Dave. The following changes since commit 10b38669d64c757cfd927e3820292c580ed70aae: Merge tag 'for-linus-v3.9-rc4' of git://oss.sgi.com/xfs/xfs (2013-03-19 15:17:40 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to b56fb70870ad76f8295a4e826dab9a9fbb0033f6: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-03-21 10:17:38 +1000) Alex Deucher (6): drm/radeon: fix S/R on VM systems (cayman/TN/SI) drm/radeon: fix backend map setup on 1 RB trinity boards drm/radeon/benchmark: make sure bo blit copy exists before using it drm/radeon/benchmark: allow same domains for dma copy drm/radeon: add support for Richland APUs drm/radeon: add Richland pci ids Ben Skeggs (2): drm/nouveau/core: fix return value of nouveau_object_del() drm/nv50/kms: prevent lockdep false-positive in page flipping path Daniel Vetter (1): MAINTAINERS: intel-gfx is no longer subscribers-only Dave Airlie (3): Merge branch 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Merge branch 'drm-fixes-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Jiri Kosina (1): drm/i915: stop using GMBUS IRQs on Gen4 chips Julia Lemire (1): drm/mgag200: Bug fix: Modified pll algorithm for EH project Kees Cook (2): drm/i915: restrict kernel address leak in debugfs drm/i915: bounds check execbuffer relocation count Martin Peres (11): drm/nv40/therm: improve selection between the old and the new style drm/nv40/therm: increase the sensor's settling delay to 20ms drm/nouveau/therm: do not make assumptions on temperature drm/nouveau/therm: remove some confusion introduced by therm_mode drm/nouveau/therm-ic: the temperature is off by sensor_constant, warn the user drm/nv40/therm: disable temperature reading if the bios misses some parameters drm/nv40/therm: reserve negative temperatures for errors drm/nouveau/therm: disable auto fan management if temperature is not available drm/nouveau/therm: disable temperature management if the sensor isn't readable drm/nouveau/therm: display the availability of the internal sensor drm/nouveau/hwmon: do not expose a buggy temperature if it is unavailable Takashi Iwai (2): Revert "drm/i915: try to train DP even harder" drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n() MAINTAINERS| 2 +- drivers/gpu/drm/i915/i915_debugfs.c| 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++- drivers/gpu/drm/i915/intel_dp.c| 14 - drivers/gpu/drm/i915/intel_i2c.c | 11 +++- drivers/gpu/drm/mgag200/mgag200_mode.c | 10 ++-- drivers/gpu/drm/nouveau/core/core/object.c | 3 +- .../gpu/drm/nouveau/core/include/subdev/therm.h| 2 +- drivers/gpu/drm/nouveau/core/subdev/therm/base.c | 18 -- drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 6 +- drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c | 67 -- drivers/gpu/drm/nouveau/core/subdev/therm/priv.h | 3 +- drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 30 +- drivers/gpu/drm/nouveau/nouveau_pm.c | 44 +- drivers/gpu/drm/nouveau/nv50_display.c | 4 +- drivers/gpu/drm/radeon/ni.c| 33 +-- drivers/gpu/drm/radeon/radeon_benchmark.c | 21 --- drivers/gpu/drm/radeon/si.c| 1 + include/drm/drm_pciids.h | 13 - 19 files changed, 204 insertions(+), 91 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #5 from Benjamin --- If I am debugging it with gdb, it won't go past the loading screen for the main menu. The last thing gdb says is "0xf776e425 in __kernel_vsyscall () ". I don't know what that means. -- 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/20130320/d471ee1b/attachment.html>
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #4 from Benjamin --- Yeah, it's segfaulting. It is 32-bit running on 64-bit Ubuntu, but I do have multiarch support (and TF2 works fine, which is nearly the same engine and also 32-bit). -- 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/20130320/bfb1d590/attachment.html>
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #3 from Benjamin --- Created attachment 76843 --> https://bugs.freedesktop.org/attachment.cgi?id=76843&action=edit Xorg.0.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/20130320/a4ab9a8a/attachment.html>
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #2 from Benjamin --- Created attachment 76842 --> https://bugs.freedesktop.org/attachment.cgi?id=76842&action=edit dmesg -- 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/20130320/2353f8e2/attachment.html>
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Also is this a 32-bit game running on a 64-bit distro? What do you mean by crash? segfault? system hangs? If it's a segfault or something like that can you get a backtrace with gdb? -- 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/20130320/e61b294e/attachment.html>
[GIT PULL] exynos-drm-fixes
Hi Dave, This pull request includes bug fixes and code cleanups. And it considers some restrictions to G2D hardware. With this, the malfunction and page fault issues to g2d driver would be fixed. If there is any problem, please kindly let me know. Thanks, Inki Dae The following changes since commit 8698080ee092bdbd6ee2cd5e7f707ceea2812bd8: Merge branch 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-03-11 13:53:58 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes Alexandru Gheorghiu (1): drm/exynos: Replaced kzalloc & memcpy with kmemdup Inki Dae (1): drm/exynos: Add a new function to get gem buffer size Leela Krishna Amudala (1): drm/exynos: fimd: calculate the correct address offset Sachin Kamat (1): drm/exynos: Make mixer_check_timing static Vikas Sajjan (1): drm/exynos: modify the compatible string for exynos fimd YoungJun Cho (6): drm/exynos: Fix error routine to getting dma addr. drm/exynos: clear node object type at gem unmap drm/exynos: Fix G2D core malfunctioning issue drm/exynos: Clean up some G2D codes for readability drm/exynos: Deal with g2d buffer info more efficiently drm/exynos: Check g2d cmd list for g2d restrictions drivers/gpu/drm/exynos/exynos_drm_fimd.c | 21 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 370 ++ drivers/gpu/drm/exynos/exynos_drm_gem.c | 21 ++ drivers/gpu/drm/exynos/exynos_drm_gem.h |5 + drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +- drivers/gpu/drm/exynos/exynos_mixer.c|2 +- 6 files changed, 365 insertions(+), 60 deletions(-)
[Bug 62573] New: Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 Priority: medium Bug ID: 62573 Assignee: dri-devel at lists.freedesktop.org Summary: Half-Life 2: Deathmatch native version crashes Severity: normal Classification: Unclassified OS: Linux (All) Reporter: brpylko at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa As the title says, the native version of HL2:DM crashes on joining or creating a server (when it loads a map I think). This does not happen under Wine nor TF2. On the github page ValveSoftware/Source-1-Games I was told that the problem lies in libgallium. glxinfo reports the renderer as "Gallium 0.4 on AMD PALM", the version as "3.0 Mesa 9.2-devel", and the shading language version as "1.30" on my machine. Would it help to post more output from glxinfo? -- 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/20130320/5baab4cd/attachment.html>
[Bug 62441] Bastion game runs slowly
https://bugs.freedesktop.org/show_bug.cgi?id=62441 --- Comment #4 from Lucas --- Well, that is embarassing... I use Linux Mint 14 64 bits (based on Ubuntu 12.10), but for testing the hypotesis I downloaded Linux Mint 14 32 bits (i.e. the same kernel version, 3.5.0), flashed a bootable USB Stick with the ISO, and booted in it. Then I ran the game out of the system's hard drive. It ran at full speed most of time, almost flawlessly. There was only a minor glitch at Warner Bros. logo during startup, and a perceivable slowdown when entering buildings like the Destilary (just GUI, irrelevant to gameplay). I am yet to revert the driver from fglrx and provide the info requested (dmesg output and xorg log), but if the radeon driver is fine (as I could atest from Live USB Stick), where is the issue? A brand new installation with functional/accelerated OpenGL should be able to run 64 bits games as well as 32 bits games, right? Where is the issue, then? In the ditribution? In the packaging? Are there missing packages that I should instal manually? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Nouveau] nouveau lockdep splat
On 03/20/2013 10:35 AM, Lijo Antony wrote: > I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git > bisect in that mail is incorrect). While investigating, I found this > issue was introduced during 3.9 merge window. For me this comes when I > connect my TV via HDMI. FWIW, git bisect gave this log, git bisect start 'drivers/gpu/' # good: [e450fcc6669705ef49784080ac6dd8513df37763] drm/tegra: Add list of framebuffers to debugfs git bisect good e450fcc6669705ef49784080ac6dd8513df37763 # bad: [6dbe51c251a327e012439c4772097a13df43c5b8] Linux 3.9-rc1 git bisect bad 6dbe51c251a327e012439c4772097a13df43c5b8 # good: [bab588fcfb6335c767d811a8955979f5440328e0] Merge tag 'soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good bab588fcfb6335c767d811a8955979f5440328e0 # good: [be88298b0a3f771a4802f20c5e66af74bfd1dff1] drm/tilcdc: only build on arm git bisect good be88298b0a3f771a4802f20c5e66af74bfd1dff1 # bad: [4d53233a36fdda567cd4d080e27e1ee4b669ddd1] drm: don't use idr_remove_all() git bisect bad 4d53233a36fdda567cd4d080e27e1ee4b669ddd1 # good: [9afa3195b96da7d2320ec44d19fbfbded7a15571] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial git bisect good 9afa3195b96da7d2320ec44d19fbfbded7a15571 # good: [496ad9aa8ef448058e36ca7a787c61f2e63f0f54] new helper: file_inode(file) git bisect good 496ad9aa8ef448058e36ca7a787c61f2e63f0f54 # bad: [d895cb1af15c04c522a25c79cc429076987c089b] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad d895cb1af15c04c522a25c79cc429076987c089b # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb -lijo
[Bug 60963] [r300g] Anno1701: some models are red
https://bugs.freedesktop.org/show_bug.cgi?id=60963 --- Comment #2 from Pavel Ondra?ka --- Created attachment 76840 --> https://bugs.freedesktop.org/attachment.cgi?id=76840&action=edit RADEON_DEBUG=noopt,fp,vp output (In reply to comment #1) > Could you post a dump with RADEON_DEBUG=noopt,vp,fp New log attached. However there is something bad going on. There are two bugs affecting this game. This one and bug 60965, however when I reported them, this bug used to disappeared with RADEON_DEBUG=noopt and bug 60965 didn't. Now when I use RADEON_DEBUG=noopt, the corruption from bug 60965 is much worse and is all over the place. The change did happened with f6c061261885fed0c83c437e9459ba79618f1b3a is the first bad commit commit f6c061261885fed0c83c437e9459ba79618f1b3a Author: Brian Paul Date: Fri Mar 1 15:16:15 2013 -0700 st/mesa: convert ir_triop_lrp to TGSI_OPCODE_LRP AFAICT, all gallium drivers implement TGSI_OPCODE_LRP. Tested with softpipe, llvmpipe, svga drivers. Reviewed-by: Matt Turner without RADEON_DEBUG=noopt the corruption is still the same, so my guess is that r300 compiler somehow doesn't like TGSI_OPCODE_LRP, optimizes is away a little bit, but not completely. -- 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/20130320/d7917c25/attachment.html>
gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Alan Stern wrote:
> > > That might be misleading. It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them. If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> >
> > I guess I should have phrased it more precisely, but that's exactly
> > what I expect is happening on my machine: I don't have anything on
> > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> > the irq is completely disabled. Which obviously makes it impossible
> > for me to reproduce the issue. To test that theory, is there a quick
> > way to force-enable a given interrupt, short of just hacking up a 2nd
> > dummy irq handler in my driver?
>
> I don't know of any way. In fact, I have been thinking of writing a
> test driver module, with a module parameter telling it which IRQ number
> to register for. It seems like the sort of thing that would be useful
> to have, from time to time.
Ok, so how about this?
Daniel, is it enough to make the problem appear on your system (by
building this into the kernel and booting with dummy-irq.irq=16)?
Thanks.
From: Jiri Kosina
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
This module accepts a single 'irq' parameter, which it should register for.
Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.
Suggested-by: Alan Stern
Signed-off-by: Jiri Kosina
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59 ++
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/dummy-irq.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..db24b79 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
TC can be used for other purposes, such as PWM generation and
interval timing.
+config DUMMY_IRQ
+ tristate "Dummy IRQ handler"
+ default n
+ ---help---
+ This module accepts a single 'irq' parameter, which it should
register for.
+ Its sole purpose is to help with debugging of IRQ sharing problems, by
+ force-enabling IRQ that would otherwise be disabled.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..4fc13e0
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs cause the IRQ to be disabled.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+ static int count = 0;
+
+ if (count == 0) {
+ printk("dummy-irq: interrupt occured on IRQ %d\n", irq);
+ count++;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+ if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
{
+ printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+ return -EIO;
+ }
+ printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+ return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+ printk(KERN_INFO "dummy-irq unloaded\n");
+ free_irq(irq, &irq);
+ return;
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param_named(irq, irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");
--
Jiri Kosina
SUSE Labs
[PATCH v2] drm/exynos: enable FIMD clocks
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patch also replaces clk_disable() with clk_disable_unprepare()
during exit.
Signed-off-by: Vikas Sajjan
---
Changes since v1:
- added error checking for clk_prepare_enable() and also replaced
clk_disable() with clk_disable_unprepare() during exit.
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..014d750 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -934,6 +934,19 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}
+ ret = clk_prepare_enable(ctx->lcd_clk);
+ if (ret) {
+ dev_err(dev, "failed to enable 'sclk_fimd' clock\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->bus_clk);
+ if (ret) {
+ clk_disable_unprepare(ctx->lcd_clk);
+ dev_err(dev, "failed to enable 'fimd' clock\n");
+ return ret;
+ }
+
ctx->vidcon0 = pdata->vidcon0;
ctx->vidcon1 = pdata->vidcon1;
ctx->default_win = pdata->default_win;
@@ -981,8 +994,8 @@ static int fimd_remove(struct platform_device *pdev)
if (ctx->suspended)
goto out;
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
pm_runtime_set_suspended(dev);
pm_runtime_put_sync(dev);
--
1.7.9.5
Re: [PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r
On Thu, Mar 21, 2013 at 12:21:21AM +0100, Jiri Kosina wrote: > On Wed, 20 Mar 2013, Alan Stern wrote: > > > > Ok, so how about this? > > > Daniel, is it enough to make the problem appear on your system (by > > > building this into the kernel and booting with dummy-irq.irq=16)? > > > > > > Thanks. > > > > > > From: Jiri Kosina > > > Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver > > > > > > This module accepts a single 'irq' parameter, which it should register > > > for. > > > > > > Its sole purpose is to help with debugging of IRQ sharing problems, by > > > force-enabling IRQ that would otherwise be disabled. > > > > > > Suggested-by: Alan Stern > > > Signed-off-by: Jiri Kosina > > > > This is just what I was thinking of. Three extremely minor > > suggestions... > > Thanks Alan. Updated version below. > > Greg, willing to merge this simple debugging facility? Yes, I'll take it, give me a few days to catch up with my pending queue, don't worry, it's not lost. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]
On Thu, Mar 21, 2013 at 12:21:21AM +0100, Jiri Kosina wrote: > On Wed, 20 Mar 2013, Alan Stern wrote: > > > > Ok, so how about this? > > > Daniel, is it enough to make the problem appear on your system (by > > > building this into the kernel and booting with dummy-irq.irq=16)? > > > > > > Thanks. > > > > > > From: Jiri Kosina > > > Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver > > > > > > This module accepts a single 'irq' parameter, which it should register > > > for. > > > > > > Its sole purpose is to help with debugging of IRQ sharing problems, by > > > force-enabling IRQ that would otherwise be disabled. > > > > > > Suggested-by: Alan Stern > > > Signed-off-by: Jiri Kosina > > > > This is just what I was thinking of. Three extremely minor > > suggestions... > > Thanks Alan. Updated version below. > > Greg, willing to merge this simple debugging facility? Yes, I'll take it, give me a few days to catch up with my pending queue, don't worry, it's not lost. greg k-h
[Nouveau] nouveau lockdep splat
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote: > # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch > 'drm-next' of git://people.freedesktop.org/~airlied/linux > git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb This is a merge commit which means something went wrong along the way of the bisection. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]
On Wed, 20 Mar 2013, Alan Stern wrote:
> > Ok, so how about this?
> > Daniel, is it enough to make the problem appear on your system (by
> > building this into the kernel and booting with dummy-irq.irq=16)?
> >
> > Thanks.
> >
> > From: Jiri Kosina
> > Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
> >
> > This module accepts a single 'irq' parameter, which it should register for.
> >
> > Its sole purpose is to help with debugging of IRQ sharing problems, by
> > force-enabling IRQ that would otherwise be disabled.
> >
> > Suggested-by: Alan Stern
> > Signed-off-by: Jiri Kosina
>
> This is just what I was thinking of. Three extremely minor
> suggestions...
Thanks Alan. Updated version below.
Greg, willing to merge this simple debugging facility?
From: Jiri Kosina
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
This module accepts a single 'irq' parameter, which it should register for.
Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.
Suggested-by: Alan Stern
Signed-off-by: Jiri Kosina
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59 ++
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/dummy-irq.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..69bb79d 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
TC can be used for other purposes, such as PWM generation and
interval timing.
+config DUMMY_IRQ
+ tristate "Dummy IRQ handler"
+ default n
+ ---help---
+ This module accepts a single 'irq' parameter, which it should
register for.
+ The sole purpose of this module is to help with debugging of systems
on
+ which spurious IRQs would happen on disabled IRQ vector.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..7014167
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs would happen on disabled IRQ vector.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+ static int count = 0;
+
+ if (count == 0) {
+ printk(KERN_INFO "dummy-irq: interrupt occured on IRQ %d\n",
+ irq);
+ count++;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+ if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
{
+ printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+ return -EIO;
+ }
+ printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+ return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+ printk(KERN_INFO "dummy-irq unloaded\n");
+ free_irq(irq, &irq);
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param(irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Yinghai Lu wrote: > > I guess I should have phrased it more precisely, but that's exactly > > what I expect is happening on my machine: I don't have anything on > > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence > > the irq is completely disabled. Which obviously makes it impossible > > for me to reproduce the issue. To test that theory, is there a quick > > way to force-enable a given interrupt, short of just hacking up a 2nd > > dummy irq handler in my driver? > > You may try to add another request_irq() > after i915_load_modeset_init==>drm_irq_install. > That could install one dummy action for ioapic irq for i915. > > Also you may need to add one quirk that does not disable intx during > msi enabling like: > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, > 0x2e22, > quirk_msi_intx_disable_bug); > This seemed to be really promising idea to me, as the DisINTx+ vs INTx+ discrepancy is very good hint, but unfortunately, after applying this: --- drivers/pci/quirks.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 0369fb6..8508e24 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2643,6 +2643,9 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1073, quirk_msi_intx_disable_bug); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1083, quirk_msi_intx_disable_bug); + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2a42, + quirk_msi_intx_disable_bug); #endif /* CONFIG_PCI_MSI */ /* Allow manual resource allocation for PCI hotplug bridges The problem is still there ... so the inconsistency between DisINTx+ and INTx+ is unfortunately not the whole story. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 17/21] modetest: Give the CRTC ID to the -P option
Hi Rob, On Tuesday 19 March 2013 14:21:32 Rob Clark wrote: > On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart wrote: > > Planes are associated with CRTCs, not connectors. Don't try to be too > > clever, use the CRTC ID in the -P option. This prepares for splitting > > CRTC and planes setup. > > hmm, I was thinking that it would be nice to someday make modetest clever > enough to deal w/ connector names instead of connector-id.. That's a good idea (and it shouldn't be too difficult to implement). > this kinda goes in the opposite direction. Please note that I use the CRTC ID instead of the connector ID for planes setup only. Planes are associated with a CRTC, not a connector. I thus thought it made sense to use the CRTC ID in the argument. If you think that's a bad idea I can drop the patch. Should modetest then associate the planes with the CRTC currently associated with the given connector ? -- Regards, Laurent Pinchart
[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black
https://bugs.freedesktop.org/show_bug.cgi?id=60503 --- Comment #12 from Pavel Ondra?ka --- (In reply to comment #11) > Created attachment 76797 [details] [review] > Possible fix v3 > > Does this patch help? Yes, this one fixes it. -- 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/20130320/2469b5ca/attachment.html>
[Bug 10642] via DRM Unimplemented DMA HEADER command (HALCYON_CMDB)
https://bugs.freedesktop.org/show_bug.cgi?id=10642 James Simmons changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from James Simmons --- Mesa is not supported at this time. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62578] r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
https://bugs.freedesktop.org/show_bug.cgi?id=62578 --- Comment #2 from Orion Poplawski --- The problem is also present in mesa 9.0.3. With that I also get the following in dmesg: Mar 20 13:51:28 aspen kernel: [162904.454217] [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer ! Mar 20 13:51:28 aspen kernel: [162904.454224] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! But I don't seem to get that with 9.1. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #15 from Eugene Shalygin --- (In reply to comment #14) Also tried both suggestions. Both changes together allows me to run `kwin --replace` with active kwin_gles. However, when I connect a second screen, it crashes (signal 7) with the same backtrace. When I toggle desktop effects, it crashes also. -- 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/20130320/d9338c8e/attachment-0001.html>
[Bug 62578] r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
https://bugs.freedesktop.org/show_bug.cgi?id=62578 --- Comment #1 from Orion Poplawski --- Downgrading from llvm-libs-3.2-2.fc18 and mesa 9.1-1.fc18 to llvm-libs-3.1-11.fc18 and mesa 9.0.1-1.fc18 appears to fix the issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62577] [r600g] GPU lockup when playing WoW with HD6450 without htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=62577 --- Comment #1 from Alex Deucher --- Is this a regression? if so can you bisect? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62578] New: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
https://bugs.freedesktop.org/show_bug.cgi?id=62578 Priority: medium Bug ID: 62578 Assignee: dri-devel@lists.freedesktop.org Summary: r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state! Severity: major Classification: Unclassified OS: All Reporter: or...@cora.nwra.com Hardware: x86 (IA32) Status: NEW Version: 9.1 Component: Drivers/DRI/r300 Product: Mesa Created attachment 76846 --> https://bugs.freedesktop.org/attachment.cgi?id=76846&action=edit Xorg.0.log Running KDE 4.10.1 on Fedora 18. After login, screen flickers a bit but nothing is displayed other than the background image. .xsession-errors contains: OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV370 OpenGL version string: 2.1 Mesa 9.1 OpenGL shading language version string: 1.20 Driver: R300G GPU class: R300 OpenGL version: 2.1 GLSL version: 1.20 Mesa version: 9.1 Linux kernel version: 3.8.3 Direct rendering: yes Requires strict binding:yes GLSL shaders: limited Texture NPOT support: limited Virtual Machine:no r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state! this r300 messages keeps repeating. kernel 3.8.3-203.fc18.i686.PAE 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)] Just updated from Fedora 16 where this system was working fine. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] xfree86: Handle drm race condition
On Wed, Mar 20, 2013 at 09:40:04AM +0100, Maarten Lankhorst wrote: > Is the drmSetInterfaceVersion call really needed here? If I look at > DRM_IOCTL_GET_UNIQUE, > I don't see any requirement of drm master or anything, so it looks to me like > for this specific race > the drmSetInterfaceVersion call can be skipped entirely without any side > effects. > This would end up with cleaner code here, and drop the master requirement > entirely. Indeed, it does look like drmSetVersion() at that point is overkill. Instead we will hit the race later in the drivers. For the purposes of clearer code, we could happily lose that drmSetVersion(). > Of course there's still a race that needs to be investigated, and is > currently not completely understood, I think. We are all in agreement. Ultimately we want to root cause the race, in the meantime we need a fallback to make sure that no desktop is left behind! -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black
https://bugs.freedesktop.org/show_bug.cgi?id=60503 --- Comment #13 from Pavel Ondračka --- BTW i did a quick tests piglit run with your patch on my RV530 with no regressions (no fixes either except 2 tests in EXT_framebuffer_multisample group, however those seems to be fairly random... ) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62577] New: [r600g] GPU lockup when playing WoW with HD6450 without htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=62577 Priority: medium Bug ID: 62577 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g] GPU lockup when playing WoW with HD6450 without htile enabled Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ranki...@googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 76845 --> https://bugs.freedesktop.org/attachment.cgi?id=76845&action=edit dmesg output showing GPU lockup Just tried to play WoW against Mesa git, having already set R600_HYPERZ=0 to work around bug #61747. This resulted in a GPU lockup after a few minutes. git HEAD is: commit d24819dce8cf6dac23f27df46fabbf756a732229 Author: Kenneth Graunke Date: Mon Mar 11 11:10:34 2013 -0700 i965/vs: Add IR dumping for immediates. This makes dump_instructions more useful. Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
freeze with drm/i915
On Wed, Mar 20, 2013 at 12:34 PM, Francesco Allertsen wrote: > I have experienced since few kernel releases some freezes of my PC. The > freeze is totally random, it can happen two times in one hour or nothing > for an entire week, and the open programs are never the same (except > maybe for Chromium). > > Last week I had the time to bisect the problem to try to solve it, > because I found that since few releases I get the following report on > dmesg: Yeah, that's a different issue and actually a long-standing bug in our display code, at least on ironlake. Which seems to be your system (I can never remember the marketing names, lspci -nn would clarify ...). We've only recently added the more obnoxious warning for it. So not really a regression. Also, this only tends to happen with a DP screen. Note that on ironlake the known hard-hang is caused by enabling rc6 (disabled by default). So if you have that set, please disable it. If that's not your hang I think we should try to capture the dying breadths of your system with netconsole to check whether anything interesting is in there. Thanks, Daniel > > [ 15.993547] [ cut here ] > [ 15.993577] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 > intel_wait_for_pipe_off+0x11b/0x126 [i915]() > [ 15.993579] Hardware name: 5129CTO > [ 15.993581] pipe_off wait timed out > [ 15.993582] Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) > vboxdrv(O) snd_hda_codec_hdmi snd_hda_codec_conexant i915 snd_hda_intel > snd_hda_codec snd_hwdep drm_kms_helper > [ 15.993593] Pid: 1566, comm: X Tainted: G O 3.8.1 #1 > [ 15.993595] Call Trace: > [ 15.993604] [] warn_slowpath_common+0x68/0x7d > [ 15.993617] [] ? intel_wait_for_pipe_off+0x11b/0x126 [i915] > [ 15.993621] [] warn_slowpath_fmt+0x2b/0x2f > [ 15.993635] [] intel_wait_for_pipe_off+0x11b/0x126 [i915] > [ 15.993649] [] intel_disable_pipe+0x115/0x11d [i915] > [ 15.993662] [] ironlake_crtc_disable+0xb2/0x688 [i915] > [ 15.993677] [] intel_set_mode+0x398/0x7b0 [i915] > [ 15.993683] [] ? should_resched+0x8/0x22 > [ 15.993688] [] ? _cond_resched+0xd/0x21 > [ 15.993694] [] ? __getblk+0x28/0x282 > [ 15.993697] [] ? __find_get_block_slow+0x11c/0x12a > [ 15.993713] [] intel_crtc_set_config+0x4de/0x651 [i915] > [ 15.993718] [] drm_mode_setcrtc+0x34b/0x39d > [ 15.993721] [] ? drm_mode_setplane+0x27a/0x27a > [ 15.993725] [] drm_ioctl+0x275/0x323 > [ 15.993727] [] ? drm_mode_setplane+0x27a/0x27a > [ 15.993730] [] ? drm_version+0x8b/0x8b > [ 15.993734] [] vfs_ioctl+0x20/0x2a > [ 15.993736] [] do_vfs_ioctl+0x3eb/0x429 > [ 15.993740] [] ? fsnotify_modify+0x48/0x53 > [ 15.993743] [] ? wait_on_retry_sync_kiocb+0x44/0x44 > [ 15.993745] [] ? vfs_write+0x8a/0xac > [ 15.993748] [] sys_ioctl+0x41/0x60 > [ 15.993751] [] syscall_call+0x7/0xb > [ 15.993753] ---[ end trace fe4cfed2900ae9cb ]--- > > Then after the bisect the following is the first commit that trigger > this warning: > > 284637d9229dc1115947bb04008730844afbc059 is the first bad commit > commit 284637d9229dc1115947bb04008730844afbc059 > Author: Daniel Vetter > Date: Mon Jul 9 09:51:57 2012 +0200 > > drm/i915: WARN if the pipe won't turn off > > This seems to be the symptom of a few neat bugs, hence be more > obnoxious when this fails. > > So, it seems that there is some other bug somewhere. If you have any > idea or you need more tests from me I'm happy to figure it out. > > Currently I am using the kernel 3.8.1, but I would like to test the > latest git soon if someone has already solved it or not. My laptop is a > Lenovo X201s and this is my video card: > > 00:02.0 VGA compatible controller: Intel Corporation Core Processor > Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) > Subsystem: Lenovo Device 215a > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 44 > Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M] > Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] > Region 4: I/O ports at 1800 [size=8] > Expansion ROM at [disabled] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Address: fee0f00c Data: 41d1 > Capabilities: [d0] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [a4] PCI Advanced Features > AFCap: TP+ FLR+ > AFCtrl: FLR- > AFStatus: TP- > Kernel driver in use: i915 > > If you need more information please just let me know. > > Thank you. > > Regards, > Franc
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #5 from Benjamin --- If I am debugging it with gdb, it won't go past the loading screen for the main menu. The last thing gdb says is "0xf776e425 in __kernel_vsyscall () ". I don't know what that means. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Wed, 20 Mar 2013, Jiri Kosina wrote:
> > I don't know of any way. In fact, I have been thinking of writing a
> > test driver module, with a module parameter telling it which IRQ number
> > to register for. It seems like the sort of thing that would be useful
> > to have, from time to time.
>
> Ok, so how about this?
> Daniel, is it enough to make the problem appear on your system (by
> building this into the kernel and booting with dummy-irq.irq=16)?
>
> Thanks.
>
>
>
>
>
> From: Jiri Kosina
> Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
>
> This module accepts a single 'irq' parameter, which it should register for.
>
> Its sole purpose is to help with debugging of IRQ sharing problems, by
> force-enabling IRQ that would otherwise be disabled.
>
> Suggested-by: Alan Stern
> Signed-off-by: Jiri Kosina
This is just what I was thinking of. Three extremely minor
suggestions...
> +static irqreturn_t dummy_interrupt(int irq, void *dev_id)
> +{
> + static int count = 0;
> +
> + if (count == 0) {
> + printk("dummy-irq: interrupt occured on IRQ %d\n", irq);
You probably should put a severity level here. KERN_INFO?
> + count++;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +static int __init dummy_irq_init(void)
> +{
> + if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
> {
> + printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
> + return -EIO;
> + }
> + printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
> + return 0;
> +}
> +
> +static void __exit dummy_irq_exit(void)
> +{
> + printk(KERN_INFO "dummy-irq unloaded\n");
> + free_irq(irq, &irq);
> + return;
A return statement isn't needed here.
> +}
> +
> +module_init(dummy_irq_init);
> +module_exit(dummy_irq_exit);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jiri Kosina");
> +module_param_named(irq, irq, uint, 0444);
module_param is good enough when the parameter's name is the same as
the variable's name.
> +MODULE_PARM_DESC(irq, "The IRQ to register for");
Alan Stern
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #4 from Benjamin --- Yeah, it's segfaulting. It is 32-bit running on 64-bit Ubuntu, but I do have multiarch support (and TF2 works fine, which is nearly the same engine and also 32-bit). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #3 from Benjamin --- Created attachment 76843 --> https://bugs.freedesktop.org/attachment.cgi?id=76843&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #2 from Benjamin --- Created attachment 76842 --> https://bugs.freedesktop.org/attachment.cgi?id=76842&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62573] Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Also is this a 32-bit game running on a 64-bit distro? What do you mean by crash? segfault? system hangs? If it's a segfault or something like that can you get a backtrace with gdb? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62573] New: Half-Life 2: Deathmatch native version crashes
https://bugs.freedesktop.org/show_bug.cgi?id=62573 Priority: medium Bug ID: 62573 Assignee: dri-devel@lists.freedesktop.org Summary: Half-Life 2: Deathmatch native version crashes Severity: normal Classification: Unclassified OS: Linux (All) Reporter: brpy...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa As the title says, the native version of HL2:DM crashes on joining or creating a server (when it loads a map I think). This does not happen under Wine nor TF2. On the github page ValveSoftware/Source-1-Games I was told that the problem lies in libgallium. glxinfo reports the renderer as "Gallium 0.4 on AMD PALM", the version as "3.0 Mesa 9.2-devel", and the shading language version as "1.30" on my machine. Would it help to post more output from glxinfo? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
freeze with drm/i915
Hello everyone, I have experienced since few kernel releases some freezes of my PC. The freeze is totally random, it can happen two times in one hour or nothing for an entire week, and the open programs are never the same (except maybe for Chromium). Last week I had the time to bisect the problem to try to solve it, because I found that since few releases I get the following report on dmesg: [ 15.993547] [ cut here ] [ 15.993577] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x11b/0x126 [i915]() [ 15.993579] Hardware name: 5129CTO [ 15.993581] pipe_off wait timed out [ 15.993582] Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hda_codec_hdmi snd_hda_codec_conexant i915 snd_hda_intel snd_hda_codec snd_hwdep drm_kms_helper [ 15.993593] Pid: 1566, comm: X Tainted: G O 3.8.1 #1 [ 15.993595] Call Trace: [ 15.993604] [] warn_slowpath_common+0x68/0x7d [ 15.993617] [] ? intel_wait_for_pipe_off+0x11b/0x126 [i915] [ 15.993621] [] warn_slowpath_fmt+0x2b/0x2f [ 15.993635] [] intel_wait_for_pipe_off+0x11b/0x126 [i915] [ 15.993649] [] intel_disable_pipe+0x115/0x11d [i915] [ 15.993662] [] ironlake_crtc_disable+0xb2/0x688 [i915] [ 15.993677] [] intel_set_mode+0x398/0x7b0 [i915] [ 15.993683] [] ? should_resched+0x8/0x22 [ 15.993688] [] ? _cond_resched+0xd/0x21 [ 15.993694] [] ? __getblk+0x28/0x282 [ 15.993697] [] ? __find_get_block_slow+0x11c/0x12a [ 15.993713] [] intel_crtc_set_config+0x4de/0x651 [i915] [ 15.993718] [] drm_mode_setcrtc+0x34b/0x39d [ 15.993721] [] ? drm_mode_setplane+0x27a/0x27a [ 15.993725] [] drm_ioctl+0x275/0x323 [ 15.993727] [] ? drm_mode_setplane+0x27a/0x27a [ 15.993730] [] ? drm_version+0x8b/0x8b [ 15.993734] [] vfs_ioctl+0x20/0x2a [ 15.993736] [] do_vfs_ioctl+0x3eb/0x429 [ 15.993740] [] ? fsnotify_modify+0x48/0x53 [ 15.993743] [] ? wait_on_retry_sync_kiocb+0x44/0x44 [ 15.993745] [] ? vfs_write+0x8a/0xac [ 15.993748] [] sys_ioctl+0x41/0x60 [ 15.993751] [] syscall_call+0x7/0xb [ 15.993753] ---[ end trace fe4cfed2900ae9cb ]--- Then after the bisect the following is the first commit that trigger this warning: 284637d9229dc1115947bb04008730844afbc059 is the first bad commit commit 284637d9229dc1115947bb04008730844afbc059 Author: Daniel Vetter Date: Mon Jul 9 09:51:57 2012 +0200 drm/i915: WARN if the pipe won't turn off This seems to be the symptom of a few neat bugs, hence be more obnoxious when this fails. So, it seems that there is some other bug somewhere. If you have any idea or you need more tests from me I'm happy to figure it out. Currently I am using the kernel 3.8.1, but I would like to test the latest git soon if someone has already solved it or not. My laptop is a Lenovo X201s and this is my video card: 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 215a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0f00c Data: 41d1 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 If you need more information please just let me know. Thank you. Regards, Francesco
[PULL] drm-intel-fixes
Hi Dave, Bunch of fixes, all pretty high-priority - Fix execbuf argument checking (Kees Cook) - Optionally obfuscate kernel addresses in dumps (Kees Cook) - Two patches from Takashi Iwai to fix DP link training regressions he's seen. - intel-gfx is no longer subscribers-only (well, just no longer moderated in an annoying way for non-subscribers), update MAINTAINERS - gm45 gmbus irq fallout fix (Jiri Kosina) Cheers, Daniel The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to c12aba5aa0e60b7947bc8b6ea25ef55c4acf81a4: drm/i915: stop using GMBUS IRQs on Gen4 chips (2013-03-20 00:03:16 +0100) Daniel Vetter (1): MAINTAINERS: intel-gfx is no longer subscribers-only Jiri Kosina (1): drm/i915: stop using GMBUS IRQs on Gen4 chips Kees Cook (2): drm/i915: restrict kernel address leak in debugfs drm/i915: bounds check execbuffer relocation count Takashi Iwai (2): Revert "drm/i915: try to train DP even harder" drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n() MAINTAINERS|2 +- drivers/gpu/drm/i915/i915_debugfs.c|2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 --- drivers/gpu/drm/i915/intel_dp.c| 14 -- drivers/gpu/drm/i915/intel_i2c.c | 11 ++- 5 files changed, 32 insertions(+), 8 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 60963] [r300g] Anno1701: some models are red
https://bugs.freedesktop.org/show_bug.cgi?id=60963 --- Comment #2 from Pavel Ondračka --- Created attachment 76840 --> https://bugs.freedesktop.org/attachment.cgi?id=76840&action=edit RADEON_DEBUG=noopt,fp,vp output (In reply to comment #1) > Could you post a dump with RADEON_DEBUG=noopt,vp,fp New log attached. However there is something bad going on. There are two bugs affecting this game. This one and bug 60965, however when I reported them, this bug used to disappeared with RADEON_DEBUG=noopt and bug 60965 didn't. Now when I use RADEON_DEBUG=noopt, the corruption from bug 60965 is much worse and is all over the place. The change did happened with f6c061261885fed0c83c437e9459ba79618f1b3a is the first bad commit commit f6c061261885fed0c83c437e9459ba79618f1b3a Author: Brian Paul Date: Fri Mar 1 15:16:15 2013 -0700 st/mesa: convert ir_triop_lrp to TGSI_OPCODE_LRP AFAICT, all gallium drivers implement TGSI_OPCODE_LRP. Tested with softpipe, llvmpipe, svga drivers. Reviewed-by: Matt Turner without RADEON_DEBUG=noopt the corruption is still the same, so my guess is that r300 compiler somehow doesn't like TGSI_OPCODE_LRP, optimizes is away a little bit, but not completely. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] xfree86: Handle drm race condition
Op 20-03-13 09:40, Maarten Lankhorst schreef: > Hey, > > Op 19-03-13 22:13, Chris Wilson schreef: >> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote: >>> The drmSetMaster call is needed, but the spinning is really just waiting >>> for the workqueue to run. >>> >>> bryce's patch never worked, it just caused it to try drmsetinterfaceversion >>> for a few seconds before timing out. That call >>> was failing because his patch series never tried to obtain drm master. >> You missed that the series Bryce posted did contain the drmSetMaster() >> call inside the loop to retry drmSetVersion(). :) >> >> > Oh I must have missed that. > > Is the drmSetInterfaceVersion call really needed here? If I look at > DRM_IOCTL_GET_UNIQUE, > I don't see any requirement of drm master or anything, so it looks to me like > for this specific race > the drmSetInterfaceVersion call can be skipped entirely without any side > effects. > This would end up with cleaner code here, and drop the master requirement > entirely. > > Of course there's still a race that needs to be investigated, and is > currently not completely understood, I think. > Or worse, is that drmGetBusId call there even useful? From digging at the kernel it seems it's a per master value. So if a device is hotplugged, it wouldn't be set yet. If someone else holds master, it wouldn't be set either. In fact it would only be ever set from DRIOpenDRMMaster, but that call only happens a lot later, if it even happens at all. It seems to me like opening the fd there should be removed entirely, and the bus id should be retrieved from the udev event instead. I'll try to get something working for this. ~Maarten
Xen guest paravirtualized framebuffer with GEM
Background: In order for me to properly ask this question, let me first describe what we are trying to accomplish. We (Citrix XenClient Enterprise team http://www.citrix.com/xenclient ) are attempting to use Xen, in combination with GEM to get a zero copy paravirtualized rendering path from a guest framebuffer running on a local machine where the guest takes up a full screen window in Xorg. The intent here is to ultimately a. Get GEM to manage the memory in GTT space b. Get the guest framebuffer to render into that memory c. Get that memory displayed on an X window The approach we have taken thus far is 1. Modify libdrm/i915 kernel driver to have a new ioctl that will return an array of pfns for the pages in a gem object 2. Modify Xen to allow access to pages from multiple domains, similar to the suggestion in this thread: http://www.gossamer-threads.com/lists/xen/devel/215894?do=post_view_threaded#215894 3. Modify qemu to a. Create a gem object. b. Map the gem object. c. Pin the gem object. d. Get the pfns of the gem object, as described in 1. e. Add these pfns to the guest's framebuffer And so we come to the problem - how do you get this buffer on screen? Ideally, this would be mapped to some GL buffer, so we could use the standard GLX calls to manipulate this data. However, since all of the APIs are hardware agnostic, I'm struggling to see a path that allows us to take this GEM object, and create something we can actually get on the screen. The following post from Jessie Barnes provided some suggestions, but I'm not sure it is entirely what we want: http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_ I also just also came across Chris Wilson's new proposed userptr ioctl. https://patchwork.kernel.org/patch/2139711/ This seems very similar to what we did with the Xen specific modification...but it is still not obvious to me how to take such an object and turn it into something usable with OpenGL. So this is my question - >From a high level, does this sound like an approach that is viable? If so - how would you recommend we go about that last bit about getting the gem object on screen? If not - where do you see the architecture falling over? Is there an easier way to do what we are trying to do? Thanks for any insight you can provide. Ben -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130320/8dbea643/attachment.html>
[PATCHv2 0/3] PCI Speed Cap Fixes for ppc64
On Wed, Mar 20, 2013 at 1:24 AM, Lucas Kannebley Tavares wrote: > This patch series first implements a function called pcie_get_speed_cap_mask > in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then > it removes the latter and fixes all references to it. And ultimately, it > implements an architecture-specific version of the same function for ppc64. > > The refactor is done because the function that was used by drm is more > architecture goo than module-specific. Whilst the function also needed a > platform-specific implementation to get PCIE Gen2 speeds on ppc64. Looks good to me but we probably want some one from the pci side to take a look Reviewed-by: Jerome Glisse > > Lucas Kannebley Tavares (3): > pci: added pcie_get_speed_cap_mask function > drm: removed drm_pcie_get_speed_cap_mask function > ppc64: implemented pcibios_get_speed_cap_mask > > arch/powerpc/platforms/pseries/pci.c | 35 +++ > drivers/gpu/drm/drm_pci.c| 38 - > drivers/gpu/drm/radeon/evergreen.c |5 ++- > drivers/gpu/drm/radeon/r600.c|5 ++- > drivers/gpu/drm/radeon/rv770.c |5 ++- > drivers/pci/pci.c| 44 > ++ > include/drm/drmP.h |6 > include/linux/pci.h |6 > 8 files changed, 94 insertions(+), 50 deletions(-) > > -- > 1.7.4.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: Add device tree support to DMM
On Tue, Mar 19, 2013 at 4:36 PM, Andy Gross wrote:
> Added in detection/support for DMM devices when booting with device
> tree.
>
> Signed-off-by: Andy Gross
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 9b794c9..d84f37c 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include "omap_dmm_tiler.h"
> #include "omap_dmm_priv.h"
> @@ -968,6 +969,14 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
> };
> #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id omap_dmm_of_match[] = {
> + {.compatible = "ti,dmm", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_dmm_of_match);
> +#endif
> +
> struct platform_driver omap_dmm_driver = {
> .probe = omap_dmm_probe,
> .remove = omap_dmm_remove,
> @@ -977,6 +986,7 @@ struct platform_driver omap_dmm_driver = {
> #ifdef CONFIG_PM
> .pm = &omap_dmm_pm_ops,
> #endif
> + .of_match_table = of_match_ptr(omap_dmm_of_match),
> },
> };
>
> --
> 1.7.5.4
>
[Nouveau] nouveau lockdep splat
On 03/20/2013 12:40 AM, Peter Hurley wrote: >> >> with the hope of having the right people on CC now (finally, thanks >> Lucas :-)), here's the same splat on -rc3. Someone better take a look >> soonish, please: > > Also happens in next (on nv50 hardware). I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git bisect in that mail is incorrect). While investigating, I found this issue was introduced during 3.9 merge window. For me this comes when I connect my TV via HDMI. But for a couple of tags during bisecting, I have seen the same during boot also. -lijo
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Wed, 20 Mar 2013, Jiri Kosina wrote:
> > I don't know of any way. In fact, I have been thinking of writing a
> > test driver module, with a module parameter telling it which IRQ number
> > to register for. It seems like the sort of thing that would be useful
> > to have, from time to time.
>
> Ok, so how about this?
> Daniel, is it enough to make the problem appear on your system (by
> building this into the kernel and booting with dummy-irq.irq=16)?
>
> Thanks.
>
>
>
>
>
> From: Jiri Kosina
> Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
>
> This module accepts a single 'irq' parameter, which it should register for.
>
> Its sole purpose is to help with debugging of IRQ sharing problems, by
> force-enabling IRQ that would otherwise be disabled.
>
> Suggested-by: Alan Stern
> Signed-off-by: Jiri Kosina
This is just what I was thinking of. Three extremely minor
suggestions...
> +static irqreturn_t dummy_interrupt(int irq, void *dev_id)
> +{
> + static int count = 0;
> +
> + if (count == 0) {
> + printk("dummy-irq: interrupt occured on IRQ %d\n", irq);
You probably should put a severity level here. KERN_INFO?
> + count++;
> + }
> +
> + return IRQ_NONE;
> +}
> +
> +static int __init dummy_irq_init(void)
> +{
> + if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
> {
> + printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
> + return -EIO;
> + }
> + printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
> + return 0;
> +}
> +
> +static void __exit dummy_irq_exit(void)
> +{
> + printk(KERN_INFO "dummy-irq unloaded\n");
> + free_irq(irq, &irq);
> + return;
A return statement isn't needed here.
> +}
> +
> +module_init(dummy_irq_init);
> +module_exit(dummy_irq_exit);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jiri Kosina");
> +module_param_named(irq, irq, uint, 0444);
module_param is good enough when the parameter's name is the same as
the variable's name.
> +MODULE_PARM_DESC(irq, "The IRQ to register for");
Alan Stern
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] xfree86: Handle drm race condition
Hey, Op 19-03-13 22:13, Chris Wilson schreef: > On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote: >> The drmSetMaster call is needed, but the spinning is really just waiting for >> the workqueue to run. >> >> bryce's patch never worked, it just caused it to try drmsetinterfaceversion >> for a few seconds before timing out. That call >> was failing because his patch series never tried to obtain drm master. > You missed that the series Bryce posted did contain the drmSetMaster() > call inside the loop to retry drmSetVersion(). :) > > Oh I must have missed that. Is the drmSetInterfaceVersion call really needed here? If I look at DRM_IOCTL_GET_UNIQUE, I don't see any requirement of drm master or anything, so it looks to me like for this specific race the drmSetInterfaceVersion call can be skipped entirely without any side effects. This would end up with cleaner code here, and drop the master requirement entirely. Of course there's still a race that needs to be investigated, and is currently not completely understood, I think. ~Maarten
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Alan Stern wrote:
> > > That might be misleading. It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them. If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> >
> > I guess I should have phrased it more precisely, but that's exactly
> > what I expect is happening on my machine: I don't have anything on
> > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> > the irq is completely disabled. Which obviously makes it impossible
> > for me to reproduce the issue. To test that theory, is there a quick
> > way to force-enable a given interrupt, short of just hacking up a 2nd
> > dummy irq handler in my driver?
>
> I don't know of any way. In fact, I have been thinking of writing a
> test driver module, with a module parameter telling it which IRQ number
> to register for. It seems like the sort of thing that would be useful
> to have, from time to time.
Ok, so how about this?
Daniel, is it enough to make the problem appear on your system (by
building this into the kernel and booting with dummy-irq.irq=16)?
Thanks.
From: Jiri Kosina
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
This module accepts a single 'irq' parameter, which it should register for.
Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.
Suggested-by: Alan Stern
Signed-off-by: Jiri Kosina
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59 ++
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/dummy-irq.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..db24b79 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
TC can be used for other purposes, such as PWM generation and
interval timing.
+config DUMMY_IRQ
+ tristate "Dummy IRQ handler"
+ default n
+ ---help---
+ This module accepts a single 'irq' parameter, which it should
register for.
+ Its sole purpose is to help with debugging of IRQ sharing problems, by
+ force-enabling IRQ that would otherwise be disabled.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..4fc13e0
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs cause the IRQ to be disabled.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+ static int count = 0;
+
+ if (count == 0) {
+ printk("dummy-irq: interrupt occured on IRQ %d\n", irq);
+ count++;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+ if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
{
+ printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+ return -EIO;
+ }
+ printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+ return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+ printk(KERN_INFO "dummy-irq unloaded\n");
+ free_irq(irq, &irq);
+ return;
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param_named(irq, irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)
https://bugs.freedesktop.org/show_bug.cgi?id=62434 Maarten Lankhorst changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Maarten Lankhorst --- The size increase only happens if radeonsi is built too, and can be countered with the shared libgallium patch. The original bug described here is fixed with these 2 commits: 36320bfa54b758b34 - radeon/llvm: Link against libgallium.la to fix an undefined symbol 7c3d8301afed46cf9 - radeon/llvm: Do not link against libgallium when building statically. -- 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/20130320/26345425/attachment.html>
Xen guest paravirtualized framebuffer with GEM
Background: In order for me to properly ask this question, let me first describe what we are trying to accomplish. We (Citrix XenClient Enterprise team http://www.citrix.com/xenclient ) are attempting to use Xen, in combination with GEM to get a zero copy paravirtualized rendering path from a guest framebuffer running on a local machine where the guest takes up a full screen window in Xorg. The intent here is to ultimately a. Get GEM to manage the memory in GTT space b. Get the guest framebuffer to render into that memory c. Get that memory displayed on an X window The approach we have taken thus far is 1. Modify libdrm/i915 kernel driver to have a new ioctl that will return an array of pfns for the pages in a gem object 2. Modify Xen to allow access to pages from multiple domains, similar to the suggestion in this thread: http://www.gossamer-threads.com/lists/xen/devel/215894?do=post_view_threaded#215894 3. Modify qemu to a. Create a gem object. b. Map the gem object. c. Pin the gem object. d. Get the pfns of the gem object, as described in 1. e. Add these pfns to the guest's framebuffer And so we come to the problem - how do you get this buffer on screen? Ideally, this would be mapped to some GL buffer, so we could use the standard GLX calls to manipulate this data. However, since all of the APIs are hardware agnostic, I'm struggling to see a path that allows us to take this GEM object, and create something we can actually get on the screen. The following post from Jessie Barnes provided some suggestions, but I'm not sure it is entirely what we want: http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_ I also just also came across Chris Wilson's new proposed userptr ioctl. https://patchwork.kernel.org/patch/2139711/ This seems very similar to what we did with the Xen specific modification...but it is still not obvious to me how to take such an object and turn it into something usable with OpenGL. So this is my question - >From a high level, does this sound like an approach that is viable? If so - how would you recommend we go about that last bit about getting the gem object on screen? If not - where do you see the architecture falling over? Is there an easier way to do what we are trying to do? Thanks for any insight you can provide. Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 0/3] PCI Speed Cap Fixes for ppc64
On Wed, Mar 20, 2013 at 1:24 AM, Lucas Kannebley Tavares wrote: > This patch series first implements a function called pcie_get_speed_cap_mask > in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then > it removes the latter and fixes all references to it. And ultimately, it > implements an architecture-specific version of the same function for ppc64. > > The refactor is done because the function that was used by drm is more > architecture goo than module-specific. Whilst the function also needed a > platform-specific implementation to get PCIE Gen2 speeds on ppc64. Looks good to me but we probably want some one from the pci side to take a look Reviewed-by: Jerome Glisse > > Lucas Kannebley Tavares (3): > pci: added pcie_get_speed_cap_mask function > drm: removed drm_pcie_get_speed_cap_mask function > ppc64: implemented pcibios_get_speed_cap_mask > > arch/powerpc/platforms/pseries/pci.c | 35 +++ > drivers/gpu/drm/drm_pci.c| 38 - > drivers/gpu/drm/radeon/evergreen.c |5 ++- > drivers/gpu/drm/radeon/r600.c|5 ++- > drivers/gpu/drm/radeon/rv770.c |5 ++- > drivers/pci/pci.c| 44 > ++ > include/drm/drmP.h |6 > include/linux/pci.h |6 > 8 files changed, 94 insertions(+), 50 deletions(-) > > -- > 1.7.4.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] nouveau lockdep splat
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote: > # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch > 'drm-next' of git://people.freedesktop.org/~airlied/linux > git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb This is a merge commit which means something went wrong along the way of the bisection. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black
https://bugs.freedesktop.org/show_bug.cgi?id=60503 --- Comment #12 from Pavel Ondračka --- (In reply to comment #11) > Created attachment 76797 [details] [review] > Possible fix v3 > > Does this patch help? Yes, this one fixes it. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 17/21] modetest: Give the CRTC ID to the -P option
Hi Rob, On Tuesday 19 March 2013 14:21:32 Rob Clark wrote: > On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart wrote: > > Planes are associated with CRTCs, not connectors. Don't try to be too > > clever, use the CRTC ID in the -P option. This prepares for splitting > > CRTC and planes setup. > > hmm, I was thinking that it would be nice to someday make modetest clever > enough to deal w/ connector names instead of connector-id.. That's a good idea (and it shouldn't be too difficult to implement). > this kinda goes in the opposite direction. Please note that I use the CRTC ID instead of the connector ID for planes setup only. Planes are associated with a CRTC, not a connector. I thus thought it made sense to use the CRTC ID in the argument. If you think that's a bad idea I can drop the patch. Should modetest then associate the planes with the CRTC currently associated with the given connector ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: Add device tree support to DMM
On Tue, Mar 19, 2013 at 4:36 PM, Andy Gross wrote:
> Added in detection/support for DMM devices when booting with device
> tree.
>
> Signed-off-by: Andy Gross
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 9b794c9..d84f37c 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include "omap_dmm_tiler.h"
> #include "omap_dmm_priv.h"
> @@ -968,6 +969,14 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
> };
> #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id omap_dmm_of_match[] = {
> + {.compatible = "ti,dmm", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_dmm_of_match);
> +#endif
> +
> struct platform_driver omap_dmm_driver = {
> .probe = omap_dmm_probe,
> .remove = omap_dmm_remove,
> @@ -977,6 +986,7 @@ struct platform_driver omap_dmm_driver = {
> #ifdef CONFIG_PM
> .pm = &omap_dmm_pm_ops,
> #endif
> + .of_match_table = of_match_ptr(omap_dmm_of_match),
> },
> };
>
> --
> 1.7.5.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #15 from Eugene Shalygin --- (In reply to comment #14) Also tried both suggestions. Both changes together allows me to run `kwin --replace` with active kwin_gles. However, when I connect a second screen, it crashes (signal 7) with the same backtrace. When I toggle desktop effects, it crashes also. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] xfree86: Handle drm race condition
On Wed, Mar 20, 2013 at 09:40:04AM +0100, Maarten Lankhorst wrote: > Is the drmSetInterfaceVersion call really needed here? If I look at > DRM_IOCTL_GET_UNIQUE, > I don't see any requirement of drm master or anything, so it looks to me like > for this specific race > the drmSetInterfaceVersion call can be skipped entirely without any side > effects. > This would end up with cleaner code here, and drop the master requirement > entirely. Indeed, it does look like drmSetVersion() at that point is overkill. Instead we will hit the race later in the drivers. For the purposes of clearer code, we could happily lose that drmSetVersion(). > Of course there's still a race that needs to be investigated, and is > currently not completely understood, I think. We are all in agreement. Ultimately we want to root cause the race, in the meantime we need a fallback to make sure that no desktop is left behind! -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 3/3] ppc64: implemented pcibios_get_speed_cap_mask
On Wed, 2013-03-20 at 02:24 -0300, Lucas Kannebley Tavares wrote: > Implementation of a architecture-specific pcibios_get_speed_cap_mask. > This implementation detects bus capabilities based on OF > ibm,pcie-link-speed-stats property. The problem with your approach is that it's not a runtime detection... If the pseries machine is compiled into the kernel binary, it will override pcibios_get_speed_cap_mask() using the device-tree, regardless of whether the machine is currently booted on a pseries machine or not. This wouldn't be a big problem if the pseries pcibios_get_speed_cap_mask() was capable of doing a fallback to the generic one if the device-tree property is absent but that isn't the case. I think what you need to do is: - Make it so the generic one can be called by the override. This can look a bit tricky but it's better that way. One way to do it is to have the actual implementation be in a __pci_* variant called by the weak pcibios_* variant - Move the powerpc on to arch/powerpc/kernel/pci-common.c and make it call a ppc_md.pcibios_get_speed_cap_mask(). If the hook is absent (NULL), make it call the generic one - pseries can then populate the hook in ppc_md. with its custom variant. Cheers, Ben.
Re: freeze with drm/i915
On Wed, Mar 20, 2013 at 12:34 PM, Francesco Allertsen wrote: > I have experienced since few kernel releases some freezes of my PC. The > freeze is totally random, it can happen two times in one hour or nothing > for an entire week, and the open programs are never the same (except > maybe for Chromium). > > Last week I had the time to bisect the problem to try to solve it, > because I found that since few releases I get the following report on > dmesg: Yeah, that's a different issue and actually a long-standing bug in our display code, at least on ironlake. Which seems to be your system (I can never remember the marketing names, lspci -nn would clarify ...). We've only recently added the more obnoxious warning for it. So not really a regression. Also, this only tends to happen with a DP screen. Note that on ironlake the known hard-hang is caused by enabling rc6 (disabled by default). So if you have that set, please disable it. If that's not your hang I think we should try to capture the dying breadths of your system with netconsole to check whether anything interesting is in there. Thanks, Daniel > > [ 15.993547] [ cut here ] > [ 15.993577] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 > intel_wait_for_pipe_off+0x11b/0x126 [i915]() > [ 15.993579] Hardware name: 5129CTO > [ 15.993581] pipe_off wait timed out > [ 15.993582] Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) > vboxdrv(O) snd_hda_codec_hdmi snd_hda_codec_conexant i915 snd_hda_intel > snd_hda_codec snd_hwdep drm_kms_helper > [ 15.993593] Pid: 1566, comm: X Tainted: G O 3.8.1 #1 > [ 15.993595] Call Trace: > [ 15.993604] [] warn_slowpath_common+0x68/0x7d > [ 15.993617] [] ? intel_wait_for_pipe_off+0x11b/0x126 [i915] > [ 15.993621] [] warn_slowpath_fmt+0x2b/0x2f > [ 15.993635] [] intel_wait_for_pipe_off+0x11b/0x126 [i915] > [ 15.993649] [] intel_disable_pipe+0x115/0x11d [i915] > [ 15.993662] [] ironlake_crtc_disable+0xb2/0x688 [i915] > [ 15.993677] [] intel_set_mode+0x398/0x7b0 [i915] > [ 15.993683] [] ? should_resched+0x8/0x22 > [ 15.993688] [] ? _cond_resched+0xd/0x21 > [ 15.993694] [] ? __getblk+0x28/0x282 > [ 15.993697] [] ? __find_get_block_slow+0x11c/0x12a > [ 15.993713] [] intel_crtc_set_config+0x4de/0x651 [i915] > [ 15.993718] [] drm_mode_setcrtc+0x34b/0x39d > [ 15.993721] [] ? drm_mode_setplane+0x27a/0x27a > [ 15.993725] [] drm_ioctl+0x275/0x323 > [ 15.993727] [] ? drm_mode_setplane+0x27a/0x27a > [ 15.993730] [] ? drm_version+0x8b/0x8b > [ 15.993734] [] vfs_ioctl+0x20/0x2a > [ 15.993736] [] do_vfs_ioctl+0x3eb/0x429 > [ 15.993740] [] ? fsnotify_modify+0x48/0x53 > [ 15.993743] [] ? wait_on_retry_sync_kiocb+0x44/0x44 > [ 15.993745] [] ? vfs_write+0x8a/0xac > [ 15.993748] [] sys_ioctl+0x41/0x60 > [ 15.993751] [] syscall_call+0x7/0xb > [ 15.993753] ---[ end trace fe4cfed2900ae9cb ]--- > > Then after the bisect the following is the first commit that trigger > this warning: > > 284637d9229dc1115947bb04008730844afbc059 is the first bad commit > commit 284637d9229dc1115947bb04008730844afbc059 > Author: Daniel Vetter > Date: Mon Jul 9 09:51:57 2012 +0200 > > drm/i915: WARN if the pipe won't turn off > > This seems to be the symptom of a few neat bugs, hence be more > obnoxious when this fails. > > So, it seems that there is some other bug somewhere. If you have any > idea or you need more tests from me I'm happy to figure it out. > > Currently I am using the kernel 3.8.1, but I would like to test the > latest git soon if someone has already solved it or not. My laptop is a > Lenovo X201s and this is my video card: > > 00:02.0 VGA compatible controller: Intel Corporation Core Processor > Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) > Subsystem: Lenovo Device 215a > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 44 > Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M] > Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] > Region 4: I/O ports at 1800 [size=8] > Expansion ROM at [disabled] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Address: fee0f00c Data: 41d1 > Capabilities: [d0] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [a4] PCI Advanced Features > AFCap: TP+ FLR+ > AFCtrl: FLR- > AFStatus: TP- > Kernel driver in use: i915 > > If you need more information please just let me know. > > Thank you. > > Regards, > Franc
freeze with drm/i915
Hello everyone, I have experienced since few kernel releases some freezes of my PC. The freeze is totally random, it can happen two times in one hour or nothing for an entire week, and the open programs are never the same (except maybe for Chromium). Last week I had the time to bisect the problem to try to solve it, because I found that since few releases I get the following report on dmesg: [ 15.993547] [ cut here ] [ 15.993577] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x11b/0x126 [i915]() [ 15.993579] Hardware name: 5129CTO [ 15.993581] pipe_off wait timed out [ 15.993582] Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hda_codec_hdmi snd_hda_codec_conexant i915 snd_hda_intel snd_hda_codec snd_hwdep drm_kms_helper [ 15.993593] Pid: 1566, comm: X Tainted: G O 3.8.1 #1 [ 15.993595] Call Trace: [ 15.993604] [] warn_slowpath_common+0x68/0x7d [ 15.993617] [] ? intel_wait_for_pipe_off+0x11b/0x126 [i915] [ 15.993621] [] warn_slowpath_fmt+0x2b/0x2f [ 15.993635] [] intel_wait_for_pipe_off+0x11b/0x126 [i915] [ 15.993649] [] intel_disable_pipe+0x115/0x11d [i915] [ 15.993662] [] ironlake_crtc_disable+0xb2/0x688 [i915] [ 15.993677] [] intel_set_mode+0x398/0x7b0 [i915] [ 15.993683] [] ? should_resched+0x8/0x22 [ 15.993688] [] ? _cond_resched+0xd/0x21 [ 15.993694] [] ? __getblk+0x28/0x282 [ 15.993697] [] ? __find_get_block_slow+0x11c/0x12a [ 15.993713] [] intel_crtc_set_config+0x4de/0x651 [i915] [ 15.993718] [] drm_mode_setcrtc+0x34b/0x39d [ 15.993721] [] ? drm_mode_setplane+0x27a/0x27a [ 15.993725] [] drm_ioctl+0x275/0x323 [ 15.993727] [] ? drm_mode_setplane+0x27a/0x27a [ 15.993730] [] ? drm_version+0x8b/0x8b [ 15.993734] [] vfs_ioctl+0x20/0x2a [ 15.993736] [] do_vfs_ioctl+0x3eb/0x429 [ 15.993740] [] ? fsnotify_modify+0x48/0x53 [ 15.993743] [] ? wait_on_retry_sync_kiocb+0x44/0x44 [ 15.993745] [] ? vfs_write+0x8a/0xac [ 15.993748] [] sys_ioctl+0x41/0x60 [ 15.993751] [] syscall_call+0x7/0xb [ 15.993753] ---[ end trace fe4cfed2900ae9cb ]--- Then after the bisect the following is the first commit that trigger this warning: 284637d9229dc1115947bb04008730844afbc059 is the first bad commit commit 284637d9229dc1115947bb04008730844afbc059 Author: Daniel Vetter Date: Mon Jul 9 09:51:57 2012 +0200 drm/i915: WARN if the pipe won't turn off This seems to be the symptom of a few neat bugs, hence be more obnoxious when this fails. So, it seems that there is some other bug somewhere. If you have any idea or you need more tests from me I'm happy to figure it out. Currently I am using the kernel 3.8.1, but I would like to test the latest git soon if someone has already solved it or not. My laptop is a Lenovo X201s and this is my video card: 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 215a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0f00c Data: 41d1 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 If you need more information please just let me know. Thank you. Regards, Francesco ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, Bunch of fixes, all pretty high-priority - Fix execbuf argument checking (Kees Cook) - Optionally obfuscate kernel addresses in dumps (Kees Cook) - Two patches from Takashi Iwai to fix DP link training regressions he's seen. - intel-gfx is no longer subscribers-only (well, just no longer moderated in an annoying way for non-subscribers), update MAINTAINERS - gm45 gmbus irq fallout fix (Jiri Kosina) Cheers, Daniel The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to c12aba5aa0e60b7947bc8b6ea25ef55c4acf81a4: drm/i915: stop using GMBUS IRQs on Gen4 chips (2013-03-20 00:03:16 +0100) Daniel Vetter (1): MAINTAINERS: intel-gfx is no longer subscribers-only Jiri Kosina (1): drm/i915: stop using GMBUS IRQs on Gen4 chips Kees Cook (2): drm/i915: restrict kernel address leak in debugfs drm/i915: bounds check execbuffer relocation count Takashi Iwai (2): Revert "drm/i915: try to train DP even harder" drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n() MAINTAINERS|2 +- drivers/gpu/drm/i915/i915_debugfs.c|2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 --- drivers/gpu/drm/i915/intel_dp.c| 14 -- drivers/gpu/drm/i915/intel_i2c.c | 11 ++- 5 files changed, 32 insertions(+), 8 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-fixes
Hi Dave, This pull request includes bug fixes and code cleanups. And it considers some restrictions to G2D hardware. With this, the malfunction and page fault issues to g2d driver would be fixed. If there is any problem, please kindly let me know. Thanks, Inki Dae The following changes since commit 8698080ee092bdbd6ee2cd5e7f707ceea2812bd8: Merge branch 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-03-11 13:53:58 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes Alexandru Gheorghiu (1): drm/exynos: Replaced kzalloc & memcpy with kmemdup Inki Dae (1): drm/exynos: Add a new function to get gem buffer size Leela Krishna Amudala (1): drm/exynos: fimd: calculate the correct address offset Sachin Kamat (1): drm/exynos: Make mixer_check_timing static Vikas Sajjan (1): drm/exynos: modify the compatible string for exynos fimd YoungJun Cho (6): drm/exynos: Fix error routine to getting dma addr. drm/exynos: clear node object type at gem unmap drm/exynos: Fix G2D core malfunctioning issue drm/exynos: Clean up some G2D codes for readability drm/exynos: Deal with g2d buffer info more efficiently drm/exynos: Check g2d cmd list for g2d restrictions drivers/gpu/drm/exynos/exynos_drm_fimd.c | 21 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 370 ++ drivers/gpu/drm/exynos/exynos_drm_gem.c | 21 ++ drivers/gpu/drm/exynos/exynos_drm_gem.h |5 + drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +- drivers/gpu/drm/exynos/exynos_mixer.c|2 +- 6 files changed, 365 insertions(+), 60 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] xfree86: Handle drm race condition
Op 20-03-13 09:40, Maarten Lankhorst schreef: > Hey, > > Op 19-03-13 22:13, Chris Wilson schreef: >> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote: >>> The drmSetMaster call is needed, but the spinning is really just waiting >>> for the workqueue to run. >>> >>> bryce's patch never worked, it just caused it to try drmsetinterfaceversion >>> for a few seconds before timing out. That call >>> was failing because his patch series never tried to obtain drm master. >> You missed that the series Bryce posted did contain the drmSetMaster() >> call inside the loop to retry drmSetVersion(). :) >> >> > Oh I must have missed that. > > Is the drmSetInterfaceVersion call really needed here? If I look at > DRM_IOCTL_GET_UNIQUE, > I don't see any requirement of drm master or anything, so it looks to me like > for this specific race > the drmSetInterfaceVersion call can be skipped entirely without any side > effects. > This would end up with cleaner code here, and drop the master requirement > entirely. > > Of course there's still a race that needs to be investigated, and is > currently not completely understood, I think. > Or worse, is that drmGetBusId call there even useful? From digging at the kernel it seems it's a per master value. So if a device is hotplugged, it wouldn't be set yet. If someone else holds master, it wouldn't be set either. In fact it would only be ever set from DRIOpenDRMMaster, but that call only happens a lot later, if it even happens at all. It seems to me like opening the fd there should be removed entirely, and the bus id should be retrieved from the udev event instead. I'll try to get something working for this. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60963] [r300g] Anno1701: some models are red
https://bugs.freedesktop.org/show_bug.cgi?id=60963 --- Comment #1 from Tom Stellard --- Could you post a dump with RADEON_DEBUG=noopt,vp,fp -- 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/20130320/9a1b6857/attachment.html>
[Bug 60503] [r300g] Unigine Heaven 3.0: all objects are black
https://bugs.freedesktop.org/show_bug.cgi?id=60503 Tom Stellard changed: What|Removed |Added Attachment #74520|0 |1 is obsolete|| --- Comment #11 from Tom Stellard --- Created attachment 76797 --> https://bugs.freedesktop.org/attachment.cgi?id=76797&action=edit Possible fix v3 Does this patch help? -- 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/20130320/532e323f/attachment-0001.html>
[PATCHv2 3/3] ppc64: implemented pcibios_get_speed_cap_mask
Implementation of a architecture-specific pcibios_get_speed_cap_mask.
This implementation detects bus capabilities based on OF
ibm,pcie-link-speed-stats property.
Signed-off-by: Lucas Kannebley Tavares
---
arch/powerpc/platforms/pseries/pci.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pci.c
b/arch/powerpc/platforms/pseries/pci.c
index 0b580f4..4da8deb 100644
--- a/arch/powerpc/platforms/pseries/pci.c
+++ b/arch/powerpc/platforms/pseries/pci.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -108,3 +109,37 @@ static void fixup_winbond_82c105(struct pci_dev* dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
fixup_winbond_82c105);
+
+int pcibios_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
+{
+ struct device_node *dn, *pdn;
+ const uint32_t *pcie_link_speed_stats = NULL;
+
+ *mask = 0;
+ dn = pci_bus_to_OF_node(dev->bus);
+
+ /* Find nearest ibm,pcie-link-speed-stats, walking up the device tree */
+ for (pdn = dn; pdn != NULL; pdn = pdn->parent) {
+ pcie_link_speed_stats = (const uint32_t *) of_get_property(pdn,
+ "ibm,pcie-link-speed-stats", NULL);
+ if (pcie_link_speed_stats != NULL)
+ break;
+ }
+
+ if (pcie_link_speed_stats == NULL) {
+ dev_info(&dev->dev, "no ibm,pcie-link-speed-stats property\n");
+ return -EINVAL;
+ }
+
+ switch (pcie_link_speed_stats[0]) {
+ case 0x02:
+ *mask |= PCIE_SPEED_50;
+ case 0x01:
+ *mask |= PCIE_SPEED_25;
+ case 0x00:
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
--
1.7.4.4
[PATCHv2 2/3] drm: removed drm_pcie_get_speed_cap_mask function
This function was moved to the pci subsystem where it fits better, as
this is much more of a generic pci task, than a drm specific one. All
references to the function (all in the radeon driver) are updated.
This is the second step in moving function drm_pcie_get_speed_cap_mask
from the drm subsystem to the pci one.
Signed-off-by: Lucas Kannebley Tavares
---
drivers/gpu/drm/drm_pci.c | 38
drivers/gpu/drm/radeon/evergreen.c |5 ++-
drivers/gpu/drm/radeon/r600.c |5 ++-
drivers/gpu/drm/radeon/rv770.c |5 ++-
include/drm/drmP.h |6 -
5 files changed, 9 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index bd719e9..ba70844 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -439,44 +439,6 @@ int drm_pci_init(struct drm_driver *driver, struct
pci_driver *pdriver)
return 0;
}
-int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
-{
- struct pci_dev *root;
- u32 lnkcap, lnkcap2;
-
- *mask = 0;
- if (!dev->pdev)
- return -EINVAL;
-
- root = dev->pdev->bus->self;
-
- /* we've been informed via and serverworks don't make the cut */
- if (root->vendor == PCI_VENDOR_ID_VIA ||
- root->vendor == PCI_VENDOR_ID_SERVERWORKS)
- return -EINVAL;
-
- pcie_capability_read_dword(root, PCI_EXP_LNKCAP, &lnkcap);
- pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, &lnkcap2);
-
- if (lnkcap2) { /* PCIe r3.0-compliant */
- if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
- *mask |= DRM_PCIE_SPEED_25;
- if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
- *mask |= DRM_PCIE_SPEED_50;
- if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
- *mask |= DRM_PCIE_SPEED_80;
- } else {/* pre-r3.0 */
- if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
- *mask |= DRM_PCIE_SPEED_25;
- if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
- *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
- }
-
- DRM_INFO("probing gen 2 caps for device %x:%x = %x/%x\n", root->vendor,
root->device, lnkcap, lnkcap2);
- return 0;
-}
-EXPORT_SYMBOL(drm_pcie_get_speed_cap_mask);
-
#else
int drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..6ba204d 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include "radeon.h"
#include "radeon_asic.h"
@@ -3871,11 +3872,11 @@ void evergreen_pcie_gen2_enable(struct radeon_device
*rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
+ ret = pcie_get_speed_cap_mask(rdev->ddev->pdev, &mask);
if (ret != 0)
return;
- if (!(mask & DRM_PCIE_SPEED_50))
+ if (!(mask & PCIE_SPEED_50))
return;
speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0740db3..89a7387 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include "radeon.h"
@@ -4371,11 +4372,11 @@ static void r600_pcie_gen2_enable(struct radeon_device
*rdev)
if (rdev->family <= CHIP_R600)
return;
- ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
+ ret = pcie_get_speed_cap_mask(rdev->ddev->pdev, &mask);
if (ret != 0)
return;
- if (!(mask & DRM_PCIE_SPEED_50))
+ if (!(mask & PCIE_SPEED_50))
return;
speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index d63fe1d..81c7f1c 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include "radeon.h"
#include "radeon_asic.h"
@@ -1254,11 +1255,11 @@ static void rv770_pcie_gen2_enable(struct radeon_device
*rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
+ ret = pcie_get_speed_cap_mask(rdev->ddev->pdev, &mask);
if (ret != 0)
return;
- if (!(mask & DRM_PCIE_SPEED_50))
+ if (!(mask & PCIE_SPEED_50))
return;
DRM_INFO("enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0\n");
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..39b2872 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1788,12 +1788
[PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function
Added function to gather the speed cap for a device and return a mask to
supported speeds. The function is divided into an interface and a weak
implementation so that architecture-specific functions can be called.
This is the first step in moving function drm_pcie_get_speed_cap_mask
from the drm subsystem to the pci one.
Signed-off-by: Lucas Kannebley Tavares
---
drivers/pci/pci.c | 44
include/linux/pci.h |6 ++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b099e00..d94ab79 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3931,6 +3931,50 @@ static int __init pci_setup(char *str)
}
early_param("pci", pci_setup);
+int __weak pcibios_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
+{
+ struct pci_dev *root;
+ u32 lnkcap, lnkcap2;
+
+ *mask = 0;
+ if (!dev)
+ return -EINVAL;
+
+ root = dev->bus->self;
+
+ /* we've been informed via and serverworks don't make the cut */
+ if (root->vendor == PCI_VENDOR_ID_VIA ||
+ root->vendor == PCI_VENDOR_ID_SERVERWORKS)
+ return -EINVAL;
+
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP, &lnkcap);
+ pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, &lnkcap2);
+
+ if (lnkcap2) { /* PCIe r3.0-compliant */
+ if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
+ *mask |= PCIE_SPEED_25;
+ if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
+ *mask |= PCIE_SPEED_50;
+ if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
+ *mask |= PCIE_SPEED_80;
+ } else {/* pre-r3.0 */
+ if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
+ *mask |= PCIE_SPEED_25;
+ if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
+ *mask |= (PCIE_SPEED_25 | PCIE_SPEED_50);
+ }
+
+ dev_info(&dev->dev, "probing gen 2 caps for device %x:%x = %x/%x\n",
+ root->vendor, root->device, lnkcap, lnkcap2);
+ return 0;
+}
+
+int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
+{
+ return pcibios_get_speed_cap_mask(dev, mask);
+}
+EXPORT_SYMBOL(pcie_get_speed_cap_mask);
+
EXPORT_SYMBOL(pci_reenable_device);
EXPORT_SYMBOL(pci_enable_device_io);
EXPORT_SYMBOL(pci_enable_device_mem);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2461033a..24a2f63 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1861,4 +1861,10 @@ static inline struct eeh_dev *pci_dev_to_eeh_dev(struct
pci_dev *pdev)
*/
struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
+#define PCIE_SPEED_25 1
+#define PCIE_SPEED_50 2
+#define PCIE_SPEED_80 4
+
+extern int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *speed_mask);
+
#endif /* LINUX_PCI_H */
--
1.7.4.4
[PATCHv2 0/3] PCI Speed Cap Fixes for ppc64
This patch series first implements a function called pcie_get_speed_cap_mask in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then it removes the latter and fixes all references to it. And ultimately, it implements an architecture-specific version of the same function for ppc64. The refactor is done because the function that was used by drm is more architecture goo than module-specific. Whilst the function also needed a platform-specific implementation to get PCIE Gen2 speeds on ppc64. Lucas Kannebley Tavares (3): pci: added pcie_get_speed_cap_mask function drm: removed drm_pcie_get_speed_cap_mask function ppc64: implemented pcibios_get_speed_cap_mask arch/powerpc/platforms/pseries/pci.c | 35 +++ drivers/gpu/drm/drm_pci.c| 38 - drivers/gpu/drm/radeon/evergreen.c |5 ++- drivers/gpu/drm/radeon/r600.c|5 ++- drivers/gpu/drm/radeon/rv770.c |5 ++- drivers/pci/pci.c| 44 ++ include/drm/drmP.h |6 include/linux/pci.h |6 8 files changed, 94 insertions(+), 50 deletions(-) -- 1.7.4.4
[Bug 62434] [bisected] 3284.073] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic)
https://bugs.freedesktop.org/show_bug.cgi?id=62434 Maarten Lankhorst changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Maarten Lankhorst --- The size increase only happens if radeonsi is built too, and can be countered with the shared libgallium patch. The original bug described here is fixed with these 2 commits: 36320bfa54b758b34 - radeon/llvm: Link against libgallium.la to fix an undefined symbol 7c3d8301afed46cf9 - radeon/llvm: Do not link against libgallium when building statically. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] xfree86: Handle drm race condition
Hey, Op 19-03-13 22:13, Chris Wilson schreef: > On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote: >> The drmSetMaster call is needed, but the spinning is really just waiting for >> the workqueue to run. >> >> bryce's patch never worked, it just caused it to try drmsetinterfaceversion >> for a few seconds before timing out. That call >> was failing because his patch series never tried to obtain drm master. > You missed that the series Bryce posted did contain the drmSetMaster() > call inside the loop to retry drmSetVersion(). :) > > Oh I must have missed that. Is the drmSetInterfaceVersion call really needed here? If I look at DRM_IOCTL_GET_UNIQUE, I don't see any requirement of drm master or anything, so it looks to me like for this specific race the drmSetInterfaceVersion call can be skipped entirely without any side effects. This would end up with cleaner code here, and drop the master requirement entirely. Of course there's still a race that needs to be investigated, and is currently not completely understood, I think. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
