[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)
https://bugzilla.kernel.org/show_bug.cgi?id=78221 --- Comment #6 from t3st3r at mail.ru --- Hmm, wrong guess about CPDMA. Trying harder, due to nature of bug it can take some time. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79997] [Dell Inspiron 6400] Laptop screen is turned off, needs shutdown to work again
https://bugs.freedesktop.org/show_bug.cgi?id=79997 --- Comment #2 from mondane.woodworker at gmail.com --- Created attachment 101513 --> https://bugs.freedesktop.org/attachment.cgi?id=101513&action=edit Xorg log as requested. The log is made after the problem occured. -- 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/20140622/bb2a0c2c/attachment.html>
[Bug 79997] [Dell Inspiron 6400] Laptop screen is turned off, needs shutdown to work again
https://bugs.freedesktop.org/show_bug.cgi?id=79997 --- Comment #3 from mondane.woodworker at gmail.com --- Created attachment 101514 --> https://bugs.freedesktop.org/attachment.cgi?id=101514&action=edit Output of dmesg as requested. The outpur is made after the problem occured using SSH. -- 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/20140622/2ce9cce0/attachment.html>
[Bug 79997] [Dell Inspiron 6400] Laptop screen is turned off, needs shutdown to work again
https://bugs.freedesktop.org/show_bug.cgi?id=79997 --- Comment #4 from mondane.woodworker at gmail.com --- Created attachment 101515 --> https://bugs.freedesktop.org/attachment.cgi?id=101515&action=edit Output of glxinfo as requested. The output is made after the problem occured. The glxinfo command had to be typed with a black screen. When using SSH, a message was showh the display couldn't be opened, which makes sense. -- 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/20140622/701fb046/attachment.html>
[Bug 78661] New: GPU sometimes locks up after boot and/or resume
https://bugzilla.kernel.org/show_bug.cgi?id=78661 Bug ID: 78661 Summary: GPU sometimes locks up after boot and/or resume Product: Drivers Version: 2.5 Kernel Version: 3.15.1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: madigens at gmail.com Regression: No I've been getting these hangs since at least 3.13.x on Ubuntu 14.04, but I remember getting them before that, too. It doesn't always happen, mostly the system works as usual. Sometimes though, I boot up or resume and upon opening an application or moving the mouse, I get a garbled screen, after a few seconds it goes back to normal, only to hang shortly thereafter again or hang completely. I can't remember this happening during normal use, meaning if it doesn't happen shortly after boot or resume, the system works fine. I cut some suspicious lines from syslog: Jun 22 10:31:40 nikolaus-desktop kernel: [ 86.067026] radeon :01:00.0: ring 5 stalled for more than 81420msec Jun 22 10:31:40 nikolaus-desktop kernel: [ 86.067034] radeon :01:00.0: GPU lockup (waiting for 0x0001 last fence id 0x on ring 5) Jun 22 10:31:41 nikolaus-desktop kernel: [ 86.929541] radeon :01:00.0: GPU reset succeeded, trying to resume Jun 22 10:31:41 nikolaus-desktop kernel: [ 86.986723] [drm] PCIE gen 2 link speeds already enabled Jun 22 10:31:41 nikolaus-desktop kernel: [ 86.988854] [drm] PCIE GART of 1024M enabled (table at 0x0025D000). Jun 22 10:31:41 nikolaus-desktop kernel: [ 86.988930] radeon :01:00.0: WB enabled Jun 22 10:31:41 nikolaus-desktop kernel: [ 86.988932] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8800d9752c00 Jun 22 10:31:41 nikolaus-desktop kernel: [ 86.988933] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x8800d9752c0c Jun 22 10:31:41 nikolaus-desktop kernel: [ 86.989307] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc90004f9c418 Jun 22 10:31:41 nikolaus-desktop kernel: [ 87.005388] [drm] ring test on 0 succeeded in 1 usecs Jun 22 10:31:41 nikolaus-desktop kernel: [ 87.005442] [drm] ring test on 3 succeeded in 1 usecs Jun 22 10:31:41 nikolaus-desktop kernel: [ 87.200919] [drm] ring test on 5 succeeded in 1 usecs Jun 22 10:31:41 nikolaus-desktop kernel: [ 87.200923] [drm] UVD initialized successfully. Jun 22 10:31:41 nikolaus-desktop kernel: [ 87.200941] [drm] ib test on ring 0 succeeded in 0 usecs Jun 22 10:31:41 nikolaus-desktop kernel: [ 87.200959] [drm] ib test on ring 3 succeeded in 1 usecs Jun 22 10:31:42 nikolaus-desktop kernel: [ 87.370683] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to get create msg (-22). Jun 22 10:31:42 nikolaus-desktop kernel: [ 87.370688] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-22). Jun 22 10:31:42 nikolaus-desktop kernel: [ 87.370708] [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed Jun 22 10:31:52 nikolaus-desktop kernel: [ 98.016760] radeon :01:00.0: ring 5 stalled for more than 1msec Jun 22 10:31:52 nikolaus-desktop kernel: [ 98.016768] radeon :01:00.0: GPU lockup (waiting for 0x0001 last fence id 0x on ring 5) Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.669107] radeon :01:00.0: GPU reset succeeded, trying to resume Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.725911] [drm] PCIE gen 2 link speeds already enabled Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.727900] [drm] PCIE GART of 1024M enabled (table at 0x0025D000). Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.727974] radeon :01:00.0: WB enabled Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.727976] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8800d9752c00 Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.727977] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x8800d9752c0c Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.728365] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc90004f9c418 Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.744428] [drm] ring test on 0 succeeded in 1 usecs Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.744483] [drm] ring test on 3 succeeded in 1 usecs Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.940008] [drm] ring test on 5 succeeded in 1 usecs Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.940012] [drm] UVD initialized successfully. Jun 22 10:45:27 nikolaus-desktop kernel: [ 912.940031] [drm] ib test on ring 0 succeeded in 0 usecs Jun 22 10:45:27 nikolaus-desktop k
[Bug 78661] GPU sometimes locks up after boot and/or resume
https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #1 from Nikolaus Waxweiler --- Argh, I forgot: I have a HD5870. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73739] RV630 massive artifacts on "Wargame European Escalation"
https://bugs.freedesktop.org/show_bug.cgi?id=73739 --- Comment #7 from Danila Shatrov --- Same problem with Radeon HD7610M on Fedora 20. -- 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/20140622/27090981/attachment.html>
[pull] drm/msm: msm-fixes for 3.16
Dave, A handful of fixes from various folks. The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee: Linux 3.16-rc2 (2014-06-21 19:02:54 -1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux msm-fixes-3.16 for you to fetch changes up to 87e956e9be0cdb832e90a4731b620286a8826842: drm/msm: fix IOMMU cleanup for -EPROBE_DEFER (2014-06-22 08:32:10 -0400) Fabian Frederick (1): drm/msm: use PAGE_ALIGNED instead of IS_ALIGNED(PAGE_SIZE) Matwey V. Kornilov (1): drm/msm: Replace type of paddr to uint32_t. Peter Griffin (1): drm/msm: storage class should be before const qualifier Stephane Viau (2): drm/msm/hdmi: set hdp clock rate before prepare_enable drm/msm: fix IOMMU cleanup for -EPROBE_DEFER drivers/gpu/drm/msm/hdmi/hdmi.c | 2 ++ drivers/gpu/drm/msm/hdmi/hdmi.h | 1 + drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 8 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 22 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 + drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/msm/msm_fbdev.c | 2 +- drivers/gpu/drm/msm/msm_gem.c | 6 ++ drivers/gpu/drm/msm/msm_iommu.c | 23 --- drivers/gpu/drm/msm/msm_mmu.h | 1 + 10 files changed, 58 insertions(+), 10 deletions(-)
[Bug 80365] New: [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed
https://bugs.freedesktop.org/show_bug.cgi?id=80365 Priority: medium Bug ID: 80365 Assignee: dri-devel at lists.freedesktop.org Summary: [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed Severity: normal Classification: Unclassified OS: Linux (All) Reporter: neatnoise at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.2 Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 101540 --> https://bugs.freedesktop.org/attachment.cgi?id=101540&action=edit dmesg Hello, Since few kernel releases I've got problems with DPM working correctly on graphics card Asus Radeon 7790 OC. Few seconds after the kernel boot messages appear: [ 11.456134] [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed [ 11.728030] [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed Tested kernel versions: 3.14.6 3.15.1 3.16-rc2 Distro: Arch linux Mesa: 10.2.1 llvm: 3.4.2 Xorg: 1.15.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/20140622/4baa5c40/attachment.html>
[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.
https://bugs.freedesktop.org/show_bug.cgi?id=80141 --- Comment #5 from Aaron B --- Created attachment 101543 --> https://bugs.freedesktop.org/attachment.cgi?id=101543&action=edit New crash of DRM that led to kernel panic on 3.16-rc2. (In reply to comment #2) > Please attach your dmesg output. What was the last kernel that was working > without problems? Added new file, I'm failing to find the kernel panic output with 3.16-rc2. It mentioned something wasn't syncing correctly so it shut everything down. It was a DRM bug from the read out. This is the log right up to before that happened, and the time stamp for page flipping failing is the same as the output from the panic so let me try to find 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/20140622/cbb24394/attachment.html>
[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750
https://bugs.freedesktop.org/show_bug.cgi?id=80235 Raul Fernandes changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Raul Fernandes --- I will open another bug to cover the crash when I have more info about that. For now, the artifacts are fixed. -- 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/20140622/549e023b/attachment.html>
[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type
On 2014/6/20 20:48, Paolo Bonzini wrote: > Il 19/06/2014 11:53, Tiejun Chen ha scritto: >> so this mean that isa bridge is still represented with Dev31:Func0 >> like the native OS. Furthermore, currently we're pushing VGA >> passthrough support into qemu upstream, and with some discussion, >> we wouldn't set the bridge class type and just expose this devfn. > > Even this is not really optimal. It just happens to work just because > QEMU's machine is currently a PCI machine with the ISA bridge on 00:01.0. > > As soon as you'll try doing integrated graphics passthrough on a PCIe > machine type (such as QEMU's "-M q35") things will break down just as > badly. > Sorry, I can't understand why this is related to the ISA bridge, 00:01.0 or even other PCIe machine type. In virtualized case we always need to create this ISA bridge as a devfn, 00:15.0, work for the i915 driver to support IGD passthrough. In qemu-xen-traditional, this ISA bridge is already created as follows: 1> We set this ISA type explicitly; 2> We register that as 00:15.0. In qemu-upstream, as you commented we can't create this as a ISA class type explicitly. So we compromise by faking this ISA bridge without ISA class type setting (as I recall you already said this way is slightly better). Maybe we will figure better way in the future. But anyway, this is always registered as 00:15.0, right? So I think the i915 driver can go back to probe the devfn like the native environment. If I'm wrong please correct me. Thanks Tiejun
[PATCH] drm: Change link order to load modules first
Given panels and I2C-connected encoders are required by DRM drivers, we need to change the link order so these are probed first. This commit moves all the i2c, panel and bridge helper drivers so they are probed before the DRM drivers. Signed-off-by: Ezequiel Garcia --- drivers/gpu/drm/Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index dd2ba42..552eaad 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -33,6 +33,10 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o CFLAGS_drm_trace_points.o := -I$(src) +obj-y += i2c/ +obj-y += panel/ +obj-y += bridge/ + obj-$(CONFIG_DRM) += drm.o obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o obj-$(CONFIG_DRM_USB) += drm_usb.o @@ -63,6 +67,3 @@ obj-$(CONFIG_DRM_QXL) += qxl/ obj-$(CONFIG_DRM_BOCHS) += bochs/ obj-$(CONFIG_DRM_MSM) += msm/ obj-$(CONFIG_DRM_TEGRA) += tegra/ -obj-y += i2c/ -obj-y += panel/ -obj-y += bridge/ -- 1.9.1
[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type
On 2014/6/20 20:32, Daniel Vetter wrote:
> Well I have no clue about forwarding the intel gpu to virtualized
> hosts and also no idea who could review this really. There's been a
> bit a discussion around the iommu mapping forwarding and similar
No, this doesn't affect IOMMU mapping.
> topics though. So I really wonder how well our driver works in this
> use case ...
In native case the truth is intel_detect_pch() needs to probe the
00:15.0 to determine what type current pch is, then the i915 driver can
be initialized correctly. Actually the 00:15.0 is just a ISA bridge.
In virtualized case we thought this ISA bridge mayn't be represented
with 00:15.0 originally by qemu-xen-traditional. So instead of checking
devfn, the i915 driver check the class type to get this ISA bridge.
But with my investigation,qemu-xen-traditional always set 00:15.0
explicitly to represent this ISA bridge. And especially, we wouldn't
provide that ISA bridge with an explicit class type in qemu-upstream, so
we need to the i915 driver to probe pch by checking devfn.
This should work both on the native case and the virtualized case.
Thanks
Tiejun
> -Daniel
>
> On Fri, Jun 20, 2014 at 11:40 AM, Chen, Tiejun
> wrote:
>> Just ping, any comments?
>>
>> Thanks
>> Tiejun
>>
>>
>> On 2014/6/19 17:53, Tiejun Chen wrote:
>>>
>>> Originally the reason to probe ISA bridge instead of Dev31:Fun0
>>> is to make graphics device passthrough work easy for VMM, that
>>> only need to expose ISA bridge to let driver know the real
>>> hardware underneath. This is a requirement from virtualization
>>> team. Especially in that virtualized environments, XEN, there
>>> is irrelevant ISA bridge in the system with that legacy qemu
>>> version specific to xen, qemu-xen-traditional. So to work
>>> reliably, we should scan through all the ISA bridge devices
>>> and check for the first match, instead of only checking the
>>> first one.
>>>
>>> But actually, qemu-xen-traditional, is always enumerated with
>>> Dev31:Fun0, 00:1f.0 as follows:
>>>
>>> hw/pt-graphics.c:
>>>
>>> intel_pch_init()
>>> |
>>> + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);
>>>
>>> so this mean that isa bridge is still represented with Dev31:Func0
>>> like the native OS. Furthermore, currently we're pushing VGA
>>> passthrough support into qemu upstream, and with some discussion,
>>> we wouldn't set the bridge class type and just expose this devfn.
>>>
>>> So we just go back to check devfn to make life normal.
>>>
>>> Signed-off-by: Tiejun Chen
>>> ---
>>>drivers/gpu/drm/i915/i915_drv.c | 19 +++
>>>1 file changed, 3 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>>> b/drivers/gpu/drm/i915/i915_drv.c
>>> index 651e65e..cb2526e 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.c
>>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>>> @@ -417,18 +417,8 @@ void intel_detect_pch(struct drm_device *dev)
>>> return;
>>> }
>>>
>>> - /*
>>> -* The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>> -* make graphics device passthrough work easy for VMM, that only
>>> -* need to expose ISA bridge to let driver know the real hardware
>>> -* underneath. This is a requirement from virtualization team.
>>> -*
>>> -* In some virtualized environments (e.g. XEN), there is
>>> irrelevant
>>> -* ISA bridge in the system. To work reliably, we should scan
>>> trhough
>>> -* all the ISA bridge devices and check for the first match,
>>> instead
>>> -* of only checking the first one.
>>> -*/
>>> - while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>> + pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>>> + if (pch) {
>>> if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>> unsigned short id = pch->device &
>>> INTEL_PCH_DEVICE_ID_MASK;
>>> dev_priv->pch_id = id;
>>> @@ -462,10 +452,7 @@ void intel_detect_pch(struct drm_device *dev)
>>> DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
>>> WARN_ON(!IS_HASWELL(dev));
>>> WARN_ON(!IS_ULT(dev));
>>> - } else
>>> - continue;
>>> -
>>> - break;
>>> + }
>>> }
>>> }
>>> if (!pch)
>>>
>>
>
>
>
unparseable, undocumented /sys/class/drm/.../pstate
On Sat, Jun 21, 2014 at 3:45 PM, Greg KH wrote: > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote: >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek wrote: >> > Hi! >> > >> > AFAICT, pstate file will contain something like >> > >> > 07: core 100 MHz memory 123 MHz * >> > 08: core 100-200 MHz memory 123 MHz >> > >> > ...which does not look exactly like one-value-per-file, and I'm pretty >> > sure userspace will get it wrong if it tries to parse it. Plus, I >> > don't see required documentation in Documentation/ABI. >> > >> > Should we disable it for now, so that userspace does not start >> > depending on it and we'll not have to maintain it forever? >> > >> > I guess better interface would be something like >> > >> > pstate/07/core_clock_min >> > core_clock_max >> > memory_clock_min >> > memory_clock_max >> > >> > and then pstate/active containing just the number of active state? >> > >> > Thanks, >> > Pavel >> > >> > PS: I have no nvidia, got the news at >> > >> > http://www.phoronix.com/scan.php?page=article&item=nouveau_try_linux316&num=2 >> >> FTR, this file has been in place since 3.13, and there was a different >> file before it (performance_levels), with a comparable format since >> much earlier (definitely 3.8, probably earlier). I think it's meant a >> lot more for people looking at it and echo'ing stuff to it to modify >> the levels (where supported), than for programs parsing it. Perhaps >> sysfs is the wrong place for this -- what is the right place? debugfs? > > Yes, please move it to debugfs. Could we just say that the format of this file is one-per-line of level: information-for-the-user And you can echo a level into it to switch to that level? That seems like a reasonable ABI to have... would be happy to throw it into a file somewhere... not sure where though. -ilia
