Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
Hi On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote: > Hi guys, > > With current git (v3.11-5058-g57d7309) I get the following oops: > > [5.434312] [ cut here ] > [5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 > __ioremap_caller+0x2e3/0x390() > [5.434321] Info: mapping multiple BARs. Your kernel is fine. > [5.434323] Modules linked in: > [5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp > brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 > crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev > iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul > ablk_helper cryptd applesmc input_polldev hwmon microcode bcma > snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate > fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel > snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button > snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight > snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 > mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod > xhci_hcd ehci_hcd usbcore usb_common > [5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted > 3.11.0-TEG-05060-g0312d0c #81 > [5.434386] Hardware name: Apple Inc. > MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 > 07/27/2012 > [5.434390] 0009 880168f87898 8145be63 > 880168f878e0 > [5.434394] 880168f878d0 8104b17d c9000c08 > a000 > [5.434398] c9000c08 c9000c08 1000 > 880168f87930 > [5.434403] Call Trace: > [5.434409] [] dump_stack+0x54/0x8d > [5.434413] [] warn_slowpath_common+0x7d/0xa0 > [5.434417] [] warn_slowpath_fmt+0x4c/0x50 > [5.434421] [] ? iomem_map_sanity_check+0xac/0xe0 > [5.434425] [] __ioremap_caller+0x2e3/0x390 > [5.434430] [] ioremap_wc+0x32/0x40 > [5.434450] [] i915_driver_load+0x670/0xf50 [i915] > [5.434467] [] ? drm_get_minor+0x1ad/0x200 > [5.434471] [] drm_get_pci_dev+0x129/0x2f0 > [5.434487] [] i915_pci_probe+0x2c/0x70 [i915] > [5.434493] [] pci_device_probe+0x84/0xe0 > [5.434502] [] driver_probe_device+0x87/0x3a0 > [5.434509] [] __driver_attach+0x93/0xa0 > [5.434516] [] ? __device_attach+0x40/0x40 > [5.434521] [] bus_for_each_dev+0x63/0xa0 > [5.434525] [] driver_attach+0x1e/0x20 > [5.434529] [] bus_add_driver+0x200/0x2d0 > [5.434533] [] ? 0xa04dbfff > [5.434538] [] driver_register+0x64/0xf0 > [5.434541] [] ? 0xa04dbfff > [5.434545] [] __pci_register_driver+0x4d/0x50 > [5.434549] [] drm_pci_init+0x115/0x130 > [5.434552] [] ? 0xa04dbfff > [5.434567] [] i915_init+0x66/0x68 [i915] > [5.434570] [] do_one_initcall+0x5a/0x1b0 > [5.434575] [] ? > __blocking_notifier_call_chain+0x58/0x70 > [5.434581] [] load_module+0x1b0a/0x25a0 > [5.434584] [] ? store_uevent+0x40/0x40 > [5.434589] [] SyS_finit_module+0x86/0xb0 > [5.434594] [] tracesys+0xdd/0xe2 > [5.434599] ---[ end trace 4f93e77fcaaac9b7 ]--- > > > > > This only happens when either simplefb or efifb is enabled. I can not > reproduce the problem on v3.11 with efifb enabled so it appears to be > new. It seems to be unrelated to the x86-sysfb changes. The WARN_ON triggered here obviously means that i915 remaps VMEM before removing efifb. So either i915 now calls ioremap and friends _before_ calling remove_conflicting_framebuffers(), or efifb is not unloaded correctly. Daniel, any ideas? Tom, some things off the top of my head: - Is efifb still running after i915 loaded? You can see that via: cat /sys/class/graphics/fb0/name (and also fb1, fb2, ... whatever is there) If it's not running, anymore, then it's quite likely an i915 issue. - Do you get a "fb: conflicting hw usage ..." in your dmesg log? - Do you get the same errors if you copy efifb.c from 3.11 over and use it instead of the new efifb.c? Thanks David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote: > On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote: >> Hi guys, >> >> With current git (v3.11-5058-g57d7309) I get the following oops: >> >> [5.434312] [ cut here ] >> [5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 >> __ioremap_caller+0x2e3/0x390() >> [5.434321] Info: mapping multiple BARs. Your kernel is fine. >> [5.434323] Modules linked in: >> [5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp >> brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 >> crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev >> iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul >> ablk_helper cryptd applesmc input_polldev hwmon microcode bcma >> snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate >> fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel >> snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button >> snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight >> snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 >> mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod >> xhci_hcd ehci_hcd usbcore usb_common >> [5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted >> 3.11.0-TEG-05060-g0312d0c #81 >> [5.434386] Hardware name: Apple Inc. >> MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 >> 07/27/2012 >> [5.434390] 0009 880168f87898 8145be63 >> 880168f878e0 >> [5.434394] 880168f878d0 8104b17d c9000c08 >> a000 >> [5.434398] c9000c08 c9000c08 1000 >> 880168f87930 >> [5.434403] Call Trace: >> [5.434409] [] dump_stack+0x54/0x8d >> [5.434413] [] warn_slowpath_common+0x7d/0xa0 >> [5.434417] [] warn_slowpath_fmt+0x4c/0x50 >> [5.434421] [] ? iomem_map_sanity_check+0xac/0xe0 >> [5.434425] [] __ioremap_caller+0x2e3/0x390 >> [5.434430] [] ioremap_wc+0x32/0x40 >> [5.434450] [] i915_driver_load+0x670/0xf50 [i915] >> [5.434467] [] ? drm_get_minor+0x1ad/0x200 >> [5.434471] [] drm_get_pci_dev+0x129/0x2f0 >> [5.434487] [] i915_pci_probe+0x2c/0x70 [i915] >> [5.434493] [] pci_device_probe+0x84/0xe0 >> [5.434502] [] driver_probe_device+0x87/0x3a0 >> [5.434509] [] __driver_attach+0x93/0xa0 >> [5.434516] [] ? __device_attach+0x40/0x40 >> [5.434521] [] bus_for_each_dev+0x63/0xa0 >> [5.434525] [] driver_attach+0x1e/0x20 >> [5.434529] [] bus_add_driver+0x200/0x2d0 >> [5.434533] [] ? 0xa04dbfff >> [5.434538] [] driver_register+0x64/0xf0 >> [5.434541] [] ? 0xa04dbfff >> [5.434545] [] __pci_register_driver+0x4d/0x50 >> [5.434549] [] drm_pci_init+0x115/0x130 >> [5.434552] [] ? 0xa04dbfff >> [5.434567] [] i915_init+0x66/0x68 [i915] >> [5.434570] [] do_one_initcall+0x5a/0x1b0 >> [5.434575] [] ? >> __blocking_notifier_call_chain+0x58/0x70 >> [5.434581] [] load_module+0x1b0a/0x25a0 >> [5.434584] [] ? store_uevent+0x40/0x40 >> [5.434589] [] SyS_finit_module+0x86/0xb0 >> [5.434594] [] tracesys+0xdd/0xe2 >> [5.434599] ---[ end trace 4f93e77fcaaac9b7 ]--- >> >> >> >> >> This only happens when either simplefb or efifb is enabled. I can not >> reproduce the problem on v3.11 with efifb enabled so it appears to be >> new. > > It seems to be unrelated to the x86-sysfb changes. The WARN_ON > triggered here obviously means that i915 remaps VMEM before removing > efifb. So either i915 now calls ioremap and friends _before_ calling > remove_conflicting_framebuffers(), or efifb is not unloaded correctly. I redid all the tests, and I'm now not able to reproduce this with efifb, only with simplefb (not sure if I made a mistake before or if some config changed). I attached the two different dmesg outputs (only difference is X86_SYSFB). > Tom, some things off the top of my head: > - Is efifb still running after i915 loaded? You can see that via: > cat /sys/class/graphics/fb0/name > (and also fb1, fb2, ... whatever is there) > If it's not running, anymore, then it's quite likely an i915 issue. I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this is after i915 has taken over from simplefb). > - Do you get a "fb: conflicting hw usage ..." in your dmesg log? Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing generic driver" -t ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
Hi On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen wrote: > On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote: >> On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote: >>> Hi guys, >>> >>> With current git (v3.11-5058-g57d7309) I get the following oops: >>> >>> [5.434312] [ cut here ] >>> [5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 >>> __ioremap_caller+0x2e3/0x390() >>> [5.434321] Info: mapping multiple BARs. Your kernel is fine. >>> [5.434323] Modules linked in: >>> [5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp >>> brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 >>> crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev >>> iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul >>> ablk_helper cryptd applesmc input_polldev hwmon microcode bcma >>> snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate >>> fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel >>> snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button >>> snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight >>> snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 >>> mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod >>> xhci_hcd ehci_hcd usbcore usb_common >>> [5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted >>> 3.11.0-TEG-05060-g0312d0c #81 >>> [5.434386] Hardware name: Apple Inc. >>> MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 >>> 07/27/2012 >>> [5.434390] 0009 880168f87898 8145be63 >>> 880168f878e0 >>> [5.434394] 880168f878d0 8104b17d c9000c08 >>> a000 >>> [5.434398] c9000c08 c9000c08 1000 >>> 880168f87930 >>> [5.434403] Call Trace: >>> [5.434409] [] dump_stack+0x54/0x8d >>> [5.434413] [] warn_slowpath_common+0x7d/0xa0 >>> [5.434417] [] warn_slowpath_fmt+0x4c/0x50 >>> [5.434421] [] ? iomem_map_sanity_check+0xac/0xe0 >>> [5.434425] [] __ioremap_caller+0x2e3/0x390 >>> [5.434430] [] ioremap_wc+0x32/0x40 >>> [5.434450] [] i915_driver_load+0x670/0xf50 [i915] >>> [5.434467] [] ? drm_get_minor+0x1ad/0x200 >>> [5.434471] [] drm_get_pci_dev+0x129/0x2f0 >>> [5.434487] [] i915_pci_probe+0x2c/0x70 [i915] >>> [5.434493] [] pci_device_probe+0x84/0xe0 >>> [5.434502] [] driver_probe_device+0x87/0x3a0 >>> [5.434509] [] __driver_attach+0x93/0xa0 >>> [5.434516] [] ? __device_attach+0x40/0x40 >>> [5.434521] [] bus_for_each_dev+0x63/0xa0 >>> [5.434525] [] driver_attach+0x1e/0x20 >>> [5.434529] [] bus_add_driver+0x200/0x2d0 >>> [5.434533] [] ? 0xa04dbfff >>> [5.434538] [] driver_register+0x64/0xf0 >>> [5.434541] [] ? 0xa04dbfff >>> [5.434545] [] __pci_register_driver+0x4d/0x50 >>> [5.434549] [] drm_pci_init+0x115/0x130 >>> [5.434552] [] ? 0xa04dbfff >>> [5.434567] [] i915_init+0x66/0x68 [i915] >>> [5.434570] [] do_one_initcall+0x5a/0x1b0 >>> [5.434575] [] ? >>> __blocking_notifier_call_chain+0x58/0x70 >>> [5.434581] [] load_module+0x1b0a/0x25a0 >>> [5.434584] [] ? store_uevent+0x40/0x40 >>> [5.434589] [] SyS_finit_module+0x86/0xb0 >>> [5.434594] [] tracesys+0xdd/0xe2 >>> [5.434599] ---[ end trace 4f93e77fcaaac9b7 ]--- >>> >>> >>> >>> >>> This only happens when either simplefb or efifb is enabled. I can not >>> reproduce the problem on v3.11 with efifb enabled so it appears to be >>> new. >> >> It seems to be unrelated to the x86-sysfb changes. The WARN_ON >> triggered here obviously means that i915 remaps VMEM before removing >> efifb. So either i915 now calls ioremap and friends _before_ calling >> remove_conflicting_framebuffers(), or efifb is not unloaded correctly. > > I redid all the tests, and I'm now not able to reproduce this with > efifb, only with simplefb (not sure if I made a mistake before or if > some config changed). I attached the two different dmesg outputs (only > difference is X86_SYSFB). > >> Tom, some things off the top of my head: >> - Is efifb still running after i915 loaded? You can see that via: >> cat /sys/class/graphics/fb0/name >> (and also fb1, fb2, ... whatever is there) >> If it's not running, anymore, then it's quite likely an i915 issue. > > I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this > is after i915 has taken over from simplefb). > >> - Do you get a "fb: conflicting hw usage ..." in your dmesg log? > > Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing > generic driver" Ok, now this makes sense. simplefb lacks the ->fb_destroy() callback so it does not correctly react to remove_conflicting_framebuffer(). But you can safely ignore the warning as simplefb is still unloaded. So it cannot be accessed anymore. It just leaks the remapping. I will send
Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
Hi Tom On Sat, Sep 7, 2013 at 3:52 PM, David Herrmann wrote: > Hi > > On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen wrote: >> On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote: >>> >>> It seems to be unrelated to the x86-sysfb changes. The WARN_ON >>> triggered here obviously means that i915 remaps VMEM before removing >>> efifb. So either i915 now calls ioremap and friends _before_ calling >>> remove_conflicting_framebuffers(), or efifb is not unloaded correctly. >> >> I redid all the tests, and I'm now not able to reproduce this with >> efifb, only with simplefb (not sure if I made a mistake before or if >> some config changed). I attached the two different dmesg outputs (only >> difference is X86_SYSFB). >> >>> Tom, some things off the top of my head: >>> - Is efifb still running after i915 loaded? You can see that via: >>> cat /sys/class/graphics/fb0/name >>> (and also fb1, fb2, ... whatever is there) >>> If it's not running, anymore, then it's quite likely an i915 issue. >> >> I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this >> is after i915 has taken over from simplefb). >> >>> - Do you get a "fb: conflicting hw usage ..." in your dmesg log? >> >> Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing >> generic driver" > > Ok, now this makes sense. simplefb lacks the ->fb_destroy() callback > so it does not correctly react to remove_conflicting_framebuffer(). > But you can safely ignore the warning as simplefb is still unloaded. > So it cannot be accessed anymore. It just leaks the remapping. > > I will send a patch later today which adds the fb_destroy() callback. Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread. Does this fix the issue (and the speed-problems)? Thanks David 0001-simplefb-fix-unmapping-fb-during-destruction.patch Description: Binary data 0002-simplefb-use-write-combined-remapping.patch Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68244] screen flickering and no sound with radeon.audio=1 when using hdmi on HD5450
https://bugs.freedesktop.org/show_bug.cgi?id=68244 --- Comment #1 from dagg --- any updates on this matter? the issue is still unresolved in kernel 3.11 I'd be happy to provide any needed outputs. -- 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 2/2] drm/radeon: add command submission tracepoint
From: Christian König
Neither complete nor perfect, but solves my problem at hand
and might be useful in the future.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c| 3 +++
drivers/gpu/drm/radeon/radeon_trace.h | 20
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index a560844..27ea004 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -28,6 +28,7 @@
#include
#include "radeon_reg.h"
#include "radeon.h"
+#include "radeon_trace.h"
static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
{
@@ -559,6 +560,8 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return r;
}
+ trace_radeon_cs(&parser);
+
r = radeon_cs_ib_chunk(rdev, &parser);
if (r) {
goto out;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
b/drivers/gpu/drm/radeon/radeon_trace.h
index a7d7c6d..f7e3678 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -27,6 +27,26 @@ TRACE_EVENT(radeon_bo_create,
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
);
+TRACE_EVENT(radeon_cs,
+ TP_PROTO(struct radeon_cs_parser *p),
+ TP_ARGS(p),
+ TP_STRUCT__entry(
+__field(u32, ring)
+__field(u32, dw)
+__field(u32, fences)
+),
+
+ TP_fast_assign(
+ __entry->ring = p->ring;
+ __entry->dw = p->chunks[p->chunk_ib_idx].length_dw;
+ __entry->fences = radeon_fence_count_emitted(
+ p->rdev, p->ring);
+ ),
+ TP_printk("ring=%u, dw=%u, fences=%u",
+ __entry->ring, __entry->dw,
+ __entry->fences)
+);
+
DECLARE_EVENT_CLASS(radeon_fence_request,
TP_PROTO(struct drm_device *dev, u32 seqno),
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: remove stale radeon_fence_retire tracepoint
From: Christian König Not used for quite a while now. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_trace.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_trace.h b/drivers/gpu/drm/radeon/radeon_trace.h index eafd816..a7d7c6d 100644 --- a/drivers/gpu/drm/radeon/radeon_trace.h +++ b/drivers/gpu/drm/radeon/radeon_trace.h @@ -53,13 +53,6 @@ DEFINE_EVENT(radeon_fence_request, radeon_fence_emit, TP_ARGS(dev, seqno) ); -DEFINE_EVENT(radeon_fence_request, radeon_fence_retire, - - TP_PROTO(struct drm_device *dev, u32 seqno), - - TP_ARGS(dev, seqno) -); - DEFINE_EVENT(radeon_fence_request, radeon_fence_wait_begin, TP_PROTO(struct drm_device *dev, u32 seqno), -- 1.8.1.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69076] New: weston+rs690: triangle flickering
https://bugs.freedesktop.org/show_bug.cgi?id=69076 Priority: medium Bug ID: 69076 Assignee: dri-devel@lists.freedesktop.org Summary: weston+rs690: triangle flickering Severity: major Classification: Unclassified OS: Linux (All) Reporter: david.heidelber...@ixit.cz Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI How to reproduce: 1.boot 2. kdm (xorg/mesa init) 3. systemctl stop kdm 4. weston // problematic 5. alt-ctrl-bckspace 6. systemctl start kdm 7. desktop (without effects or 3D) 8. logout 9. systemctl stop kdm 10. weston (without described flickering) Screenshots: http://212.158.157.7/20130907_001.jpg (weston start - triangle damaged title) http://212.158.157.7/20130907_002.jpg (first input in terminal) http://212.158.157.7/20130907_003.jpg (terminal filled) On every redraw (input from keyboard), all damaged content (triangles) flicker. Kernel 3.9.1, mesa git, llvm git, weston+wayland git. -- 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 42490] NUTMEG DP to VGA bridge not working
https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #46 from rmccork...@karoshi.org.uk --- I can confirm that this bug is still present in Linux 3.8.0, using X Server 7.7 and driver 7.1.0. As graphics are initialized screen just goes black. -- 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: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
Hi David, On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote: > On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann wrote: >> Attached are two patches. The first one should fix this issue, the >> second one is the rebased ioremap_wc() patch from the other thread. >> >> Does this fix the issue (and the speed-problems)? > > Sadly, no. I added a few printk's to verify that the function you > added is called (it is), but still the same oops. A few more datapoints: Triggers: X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded) X86_SYSFB=y and FB_SIMPLE=y Does not trigger: X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we fall back to efifb) X86_SYSFB=n and FB_EFI=y X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded) Does this make any sense? Cheers, Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
Hi On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote: > Hi David, > > On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote: >> On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann wrote: >>> Attached are two patches. The first one should fix this issue, the >>> second one is the rebased ioremap_wc() patch from the other thread. >>> >>> Does this fix the issue (and the speed-problems)? >> >> Sadly, no. I added a few printk's to verify that the function you >> added is called (it is), but still the same oops. > > A few more datapoints: > > Triggers: > X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded) > X86_SYSFB=y and FB_SIMPLE=y > > Does not trigger: > X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we > fall back to efifb) > X86_SYSFB=n and FB_EFI=y > X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded) > > Does this make any sense? Thanks a lot for these results. I think I got it know. I will write a patch that marks the resource as busy. See: kernel/resource.c iomem_map_sanity_check() It also contains a hint that we should set this for driver-resources which not directly map to hardware resources (such as veasfb and, obviously, simplefb). Following a diff which hopefully fixes this. The other two patches should still be required, though. I will try to write a proper patch tomorrow. Thanks a lot for these extensive tests, Tom! David diff --git a/arch/x86/kernel/sysfb_simplefb.c b/arch/x86/kernel/sysfb_simplefb.c index 22513e9..b7bb615 100644 --- a/arch/x86/kernel/sysfb_simplefb.c +++ b/arch/x86/kernel/sysfb_simplefb.c @@ -79,7 +79,7 @@ __init int create_simplefb(const struct screen_info *si, /* setup IORESOURCE_MEM as framebuffer memory */ memset(&res, 0, sizeof(res)); - res.flags = IORESOURCE_MEM; + res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; res.name = simplefb_resname; res.start = si->lfb_base; res.end = si->lfb_base + len - 1; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nv10/plane: add plane support for nv10-nv40
Signed-off-by: Ilia Mirkin
---
This has received light testing on NV18 and NV34 cards, using the modetest
tool. Userspace support to use this for xv is not yet ready.
I decided against creating a new "pvideo" engine -- that just seems way too
heavy-handed compared to the ~10 lines of code in disp/nv04.c to deal with the
PVIDEO interrupts.
Even though there are two possible planes, they are sufficiently linked
together that I decided to just expose them as one, and do a
double-buffering-style thing, similar to what xf86-video-nouveau did pre-KMS.
drivers/gpu/drm/nouveau/core/engine/disp/nv04.c | 9 +
drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c | 1 +
drivers/gpu/drm/nouveau/dispnv04/Makefile | 1 +
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +
drivers/gpu/drm/nouveau/dispnv04/disp.h | 3 +
drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 320
7 files changed, 342 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/dispnv04/overlay.c
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
b/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
index 05e903f..a0bc8a8 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv04.c
@@ -59,6 +59,7 @@ nv04_disp_intr(struct nouveau_subdev *subdev)
struct nv04_disp_priv *priv = (void *)subdev;
u32 crtc0 = nv_rd32(priv, 0x600100);
u32 crtc1 = nv_rd32(priv, 0x602100);
+ u32 pvideo;
if (crtc0 & 0x0001) {
nouveau_event_trigger(priv->base.vblank, 0);
@@ -69,6 +70,14 @@ nv04_disp_intr(struct nouveau_subdev *subdev)
nouveau_event_trigger(priv->base.vblank, 1);
nv_wr32(priv, 0x602100, 0x0001);
}
+
+ if (nv_device(priv)->chipset >= 0x10 &&
+ nv_device(priv)->chipset <= 0x40) {
+ pvideo = nv_rd32(priv, 0x8100);
+ if (pvideo & ~0x11)
+ nv_info(priv, "PVIDEO intr: %08x\n", pvideo);
+ nv_wr32(priv, 0x8100, pvideo);
+ }
}
static int
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
index 64aa4ed..062c048 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c
@@ -33,6 +33,7 @@ nv04_mc_intr[] = {
{ 0x0001, NVDEV_ENGINE_MPEG }, /* NV17- MPEG/ME */
{ 0x0100, NVDEV_ENGINE_FIFO },
{ 0x1000, NVDEV_ENGINE_GR },
+ { 0x0001, NVDEV_ENGINE_DISP },
{ 0x0002, NVDEV_ENGINE_VP },/* NV40- */
{ 0x0010, NVDEV_SUBDEV_TIMER },
{ 0x0100, NVDEV_ENGINE_DISP }, /* NV04- PCRTC0 */
diff --git a/drivers/gpu/drm/nouveau/dispnv04/Makefile
b/drivers/gpu/drm/nouveau/dispnv04/Makefile
index ea3f5b8..424a489 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/Makefile
+++ b/drivers/gpu/drm/nouveau/dispnv04/Makefile
@@ -5,6 +5,7 @@ nouveau-y += dispnv04/dac.o
nouveau-y += dispnv04/dfp.o
nouveau-y += dispnv04/disp.o
nouveau-y += dispnv04/hw.o
+nouveau-y += dispnv04/overlay.o
nouveau-y += dispnv04/tvmodesnv17.o
nouveau-y += dispnv04/tvnv04.o
nouveau-y += dispnv04/tvnv17.o
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 4908d3f..b13ff0f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -140,6 +140,8 @@ nv04_display_create(struct drm_device *dev)
func->save(encoder);
}
+ nouveau_overlay_init(dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 9928187..bb5c1bd 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@ -123,6 +123,9 @@ int nv04_tv_create(struct drm_connector *, struct
dcb_output *);
/* nv17_tv.c */
int nv17_tv_create(struct drm_connector *, struct dcb_output *);
+/* overlay.c */
+void nouveau_overlay_init(struct drm_device *dev);
+
static inline bool
nv_two_heads(struct drm_device *dev)
{
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index ffd2641..b1c5cd6 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -27,6 +27,7 @@
#include "hw.h"
#include
+#include
#include
#include
@@ -664,6 +665,7 @@ nv_load_state_ext(struct drm_device *dev, int head,
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_device *device = nv_device(drm->device);
struct nouveau_timer *ptimer = nouveau_timer(device);
+ struct nouveau_fb *pfb = nouveau_fb(device);
struct nv04_crtc_reg *regp = &state->crtc_reg[head];
uint32_t reg900;
int i;
@@ -680,10 +682,10 @@ nv_load_state_ext(struct drm_device *dev, int
[PATCH 1/2] modetest: add a -D option to specify a device to be used
This is helpful for differentiating between multiple devices that use
the same module.
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index f0ed56b..9d6e279 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1303,7 +1303,7 @@ static int parse_property(struct property_arg *p, const
char *arg)
static void usage(char *name)
{
- fprintf(stderr, "usage: %s [-cdefMmPpsvw]\n", name);
+ fprintf(stderr, "usage: %s [-cDdefMPpsvw]\n", name);
fprintf(stderr, "\n Query options:\n\n");
fprintf(stderr, "\t-c\tlist connectors\n");
@@ -1320,6 +1320,7 @@ static void usage(char *name)
fprintf(stderr, "\n Generic options:\n\n");
fprintf(stderr, "\t-d\tdrop master after mode set\n");
fprintf(stderr, "\t-M module\tuse the given driver\n");
+ fprintf(stderr, "\t-D device\tuse the given device\n");
fprintf(stderr, "\n\tDefault is to dump all info.\n");
exit(0);
@@ -1346,7 +1347,7 @@ static int page_flipping_supported(void)
#endif
}
-static char optstr[] = "cdefM:P:ps:vw:";
+static char optstr[] = "cdD:efM:P:ps:vw:";
int main(int argc, char **argv)
{
@@ -1357,6 +1358,7 @@ int main(int argc, char **argv)
int drop_master = 0;
int test_vsync = 0;
const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx",
"omapdrm", "exynos", "tilcdc", "msm" };
+ char *device = NULL;
char *module = NULL;
unsigned int i;
int count = 0, plane_count = 0;
@@ -1377,6 +1379,10 @@ int main(int argc, char **argv)
case 'c':
connectors = 1;
break;
+ case 'D':
+ device = optarg;
+ args--;
+ break;
case 'd':
drop_master = 1;
break;
@@ -1447,7 +1453,7 @@ int main(int argc, char **argv)
encoders = connectors = crtcs = planes = framebuffers = 1;
if (module) {
- dev.fd = drmOpen(module, NULL);
+ dev.fd = drmOpen(module, device);
if (dev.fd < 0) {
fprintf(stderr, "failed to open device '%s'.\n",
module);
return 1;
@@ -1455,7 +1461,7 @@ int main(int argc, char **argv)
} else {
for (i = 0; i < ARRAY_SIZE(modules); i++) {
printf("trying to open device '%s'...", modules[i]);
- dev.fd = drmOpen(modules[i], NULL);
+ dev.fd = drmOpen(modules[i], device);
if (dev.fd < 0) {
printf("failed.\n");
} else {
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] modetest: allow setting a scaling factor when showing plane
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 9d6e279..51c4e6d 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -707,6 +707,7 @@ struct plane_arg {
bool has_position;
int32_t x, y;
uint32_t w, h;
+ double scale;
unsigned int fb_id;
char format_str[5]; /* need to leave room for terminating \0 */
unsigned int fourcc;
@@ -988,16 +989,16 @@ static int set_plane(struct device *dev, struct plane_arg
*p)
return -1;
}
+ crtc_w = p->w * p->scale;
+ crtc_h = p->h * p->scale;
if (!p->has_position) {
/* Default to the middle of the screen */
- crtc_x = (crtc->mode->hdisplay - p->w) / 2;
- crtc_y = (crtc->mode->vdisplay - p->h) / 2;
+ crtc_x = (crtc->mode->hdisplay - crtc_w) / 2;
+ crtc_y = (crtc->mode->vdisplay - crtc_h) / 2;
} else {
crtc_x = p->x;
crtc_y = p->y;
}
- crtc_w = p->w;
- crtc_h = p->h;
/* note src coords (last 4 args) are in Q16 format */
if (drmModeSetPlane(dev->fd, plane_id, crtc->crtc->crtc_id, p->fb_id,
@@ -1271,6 +1272,15 @@ static int parse_plane(struct plane_arg *plane, const
char *p)
plane->has_position = true;
}
+ if (*end == '*') {
+ p = end + 1;
+ plane->scale = strtod(p, &end);
+ if (plane->scale <= 0.0)
+ return -EINVAL;
+ } else {
+ plane->scale = 1.0;
+ }
+
if (*end == '@') {
p = end + 1;
if (strlen(p) != 4)
@@ -1312,7 +1322,7 @@ static void usage(char *name)
fprintf(stderr, "\t-p\tlist CRTCs and planes (pipes)\n");
fprintf(stderr, "\n Test options:\n\n");
- fprintf(stderr, "\t-P :x[++][@]\tset a
plane\n");
+ fprintf(stderr, "\t-P
:x[++][*][@]\tset a plane\n");
fprintf(stderr, "\t-s
[,][@]:[@]\tset a mode\n");
fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
fprintf(stderr, "\t-w ::\tset property\n");
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] New: Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081
Priority: medium
Bug ID: 69081
Assignee: dri-devel@lists.freedesktop.org
Summary: Incorrect rendering of textures
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: j.suarez.agap...@gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/radeonsi
Product: Mesa
First of all, thank you very much for the effort applied on the radeonsi
driver. It's getting a nice shape quite quickly.
I have noticed some problems with the rendering on some games, such as Killing
Floor ("KF") and Crusader Kings II ("CK II").
The problem consists in that certain textures appear as black. This is not
related to a dxtn problem, but rather it seems to be related to the way the
(global?, in the case of CK II) illumination of the scene is applied. I have
made this conclusion based on the fact that although on CK II all the terrain
textures show a black colour (check the screenshots attached below, one of them
with radeonsi, the other one with fglrx), on KF sometimes a texture is shown
correct but a few steps ahead it is shown black. This usually happens when
there is something blocking a source of illumination (check the two screenshots
attached below, where one is taken like just one step ahead or behind of the
other screenshot, both with radeonsi).
I believe the bugs on both games are the same or at least related and thus I am
only opening a bug report.
My PC specs are as follows (taken from steam's system info):
Información sobre el procesador:
Fabricante: AuthenticAMD
CPU Family: 0x15
CPU Model: 0x1
CPU Stepping: 0x2
CPU Type: 0x0
Velocidad: 3600 Mhz
Procesadores lógicos 8
Procesadores físicos 8
HyperThreading: No compatible
FCMOV: Compatible
SSE2: Compatible
SSE3: Compatible
SSSE3: Compatible
SSE4a: Compatible
SSE41: Compatible
SSE42: Compatible
Información sobre la red:
Velocidad de la red:
Versión del sistema operativo:
Ubuntu 13.04 (64 bits)
Nombre de kernel: Linux
Versión de kernel: 3.11.0-031100-generic
Editor de X Server: The X.Org Foundation
Versión de X Server: 11303000
Gestor X Window: KWin
Versión del runtime de Steam: steam-runtime-release_2013-09-05
Tarjeta de vídeo:
Controlador: X.Org Gallium 0.4 on AMD PITCAIRN
Versión de controlador: 2.1 Mesa 9.3.0-devel (git-505fad0 raring-oibaf-ppa)
OpenGL Version: 2.1
Densidad de color del escritorio: 24 bits por píxel
Frecuencia de actualización del monitor: 60 Hz
Identificador del fabricante: 0x1002
Identificador del dispositivo: 0x6818
Número de monitores: 1
Número de tarjetas de vídeo lógicas: 1
Resolución de pantalla principal: 1920 x 1080
Resolución de escritorio: 1920 x 1080
Tamaño de pantalla principal: 18,78" x 10,55" (21,54" diag)
47,7cm x 26,8cm (54,7cm diag)
No se ha detectado la memoria VRAM principal
Tarjeta de sonido:
Dispositivo de sonido: Realtek ALC889
Memoria:
RAM: 15993 Mb
Varios:
Idioma de la IU: Español
LANG: es_ES.UTF-8
Micrófono: Not set
Espacio total en disco disponible: 469324 MB
Bloque libre más grande en el disco: 187784 MB
Software Instalado:
Informes de fallos recientes:
The GPU is a Radeon HD 7870. VRAM is 2 GB. Mesa's version is shown above (9.3
git 505fad0), plus llvm's version is 3.3-5ubuntu1~r~gd, installed from oibaf's
ppa.
I am also attaching the shader dumps from CK II and KF (in the map in which the
screenshots were taken and having passed where the bug shows).
Please, if any other information is needed, just let me know.
Regards,
José
--
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 69081] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #1 from José Suárez --- Created attachment 85409 --> https://bugs.freedesktop.org/attachment.cgi?id=85409&action=edit CK II correctly rendered (fglrx) -- 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 69081] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #2 from José Suárez --- Created attachment 85410 --> https://bugs.freedesktop.org/attachment.cgi?id=85410&action=edit CK II incorrectly rendered (radeonsi) -- 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 69081] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #3 from José Suárez --- Created attachment 85411 --> https://bugs.freedesktop.org/attachment.cgi?id=85411&action=edit CK II shaders dump -- 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 69081] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #5 from José Suárez --- Created attachment 85413 --> https://bugs.freedesktop.org/attachment.cgi?id=85413&action=edit KF textures showing black -- 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 69081] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #4 from José Suárez --- Created attachment 85412 --> https://bugs.freedesktop.org/attachment.cgi?id=85412&action=edit KF correct textures -- 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 69081] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #6 from José Suárez --- Created attachment 85414 --> https://bugs.freedesktop.org/attachment.cgi?id=85414&action=edit KF shaders dump -- 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 69081] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #7 from José Suárez --- Sorry, I forgot to add that on a Radeon HD 4570 (r600g driver) (a laptop), this/these bug/s do not show (i.e., the textures are rendered correctly). If needed, I can try to get a shader dump of CK II from that laptop. Regards, José -- 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
[REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled
Hi David, On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann wrote: > Attached are two patches. The first one should fix this issue, the > second one is the rebased ioremap_wc() patch from the other thread. > > Does this fix the issue (and the speed-problems)? Sadly, no. I added a few printk's to verify that the function you added is called (it is), but still the same oops. The slowdown is (still) fixed though :-) dmesg attached. Cheers, Tom -- next part -- A non-text attachment was scrubbed... Name: dmesg-i915-oops Type: application/octet-stream Size: 141121 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130907/20895921/attachment-0001.obj>
