[Bug 65911] radeon: garbled output/only noise through HDMI and GPU lockups
https://bugzilla.kernel.org/show_bug.cgi?id=65911 --- Comment #12 from tomka --- To verify that this problem doesn't originate from my particula operating system setup I tested recent live USB systems of Ubuntu 13.10 and Manjaro 0.8.8. Both produce the same GPU lockups and therefore can't start X on startup. So I wonder: could this actually be a hardware problem? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65911] radeon: garbled output/only noise through HDMI and GPU lockups
https://bugzilla.kernel.org/show_bug.cgi?id=65911 --- Comment #13 from tomka --- Another thing I tested was to run weston-launch from a TTY to utilize Wayland. This leads to the same distorted/garbled display. However I can't set the GPU lock up in the logs, nor is there a reset---it just seems to crash. Therefore, I assume the problem is not xf86-video-ati, but either Mesa or the radeon driver (or the hardware is broken). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65911] radeon: garbled output/only noise through HDMI and GPU lockups
https://bugzilla.kernel.org/show_bug.cgi?id=65911 --- Comment #14 from tomka --- Yet another data point: I just installed ATI's catalyst driver. Having this in place and configured, everything works as expected: I can start X and play audio through HDMI without any error. This at least means my hardware is alright. Anyway---it would still be great to be able to use mesa and the radeon driver. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 31/32] drm/exynos: Move lvds bridge discovery into DP driver
Hi Tomasz, Thanks for review, 2013/11/30 Tomasz Figa : > Hi Sean, > > On Tuesday 29 of October 2013 12:13:17 Sean Paul wrote: >> This patch moves the lvds bridge discovery and connector pre-emption >> code from exynos common code into the dp driver (since the bridge is >> only applicable for dp). >> >> Signed-off-by: Sean Paul >> --- >> >> Changes in v3: >> - Added to the patchset >> >> drivers/gpu/drm/exynos/exynos_dp_core.c | 41 >> >> drivers/gpu/drm/exynos/exynos_drm_core.c | 41 >> >> 2 files changed, 41 insertions(+), 41 deletions(-) >> > > Well, DRM bridge infrastructure is useful for more than just DP. Currently > there are several platforms that could use it with DSI as well, e.g. In case that some board with DSI bus needs this LVDS bridge, the bridge type would be MIPI-DSI to LVDS Display bridge. So I think moving this lvds stuff into eDP driver is reasonable becasue the normal DSI bus cannot use this LVDS bridge, and this bridge (eDP to LVDS) would be for eDP bus. BTW, Sean, why not implementing this lvds codes to eDP driver without previous related patch? that seems unnecessary work. > Trats, Trats2, Arndale. With a simple abstraction worth of one or at most > two days of work, we could get something that would cover much more than > just a single Chromebook. I also thought a better way is to use simple abstraction layer. But the abstraction layer I thought was the case that lvds binding is done in this lvds driver itself so drm connector should call some bridge related functions of the abstraction layer. But it seems that other maintainers don't agree to this way. :( Anyway, we can say the use of lvds bridge is dependent on board but actually, the use of lvds bridge would be more dependent on bus device or lcd panel attached to the board. So my opinion is to bind dt in the bus or lcd panel drivers that need lvds bridge. If dt binding of lvds bridge cannot be done itself, Sean's way is reasonable to me except the unnecessary patch. Thanks, Inki Dae > > Best regards, > Tomasz > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv
Hi all, How about moving this discussion to other related email thread, "[PATCH v3 31/32] drm/exynos: Move lvds bridge discovery into DP driver"? lvds related codes have already been removed from this patch and moved into eDP bus driver. It would be more good to make a dicussion about actual codes. Thanks, Inki Dae 2013/11/30 Rob Clark : > On Fri, Nov 29, 2013 at 12:05 PM, Tomasz Figa wrote: >> On Friday 29 of November 2013 09:13:19 Rob Clark wrote: >>> On Fri, Nov 29, 2013 at 4:10 AM, Tomasz Figa >>> wrote: >>> > I would mostly agree with you if we were discussing SoC-internal >>> > components here. Mostly, because the ARM world is more complex and you >>> > can see the same IP across completely different SoCs from different >>> > vendors. >>> > >>> > However, the topic here is about external devices, outside the SoC, such >>> > as different kind of bridges, like the PTN3460 eDP to LVDS bridge, which >>> > are likely to be reused across different platforms. Similar thing is with >>> > using different bridges on different boards using the same SoC platform. >>> > I don't think having an abstraction here would be any overabstraction at >>> > all. Anything less would be a huge "underabstraction" in fact. >>> >>> >>> I think no one is arguing that we don't eventually need some better >>> abstraction. But as long as it is one-bridge and one-user, if the >>> patches otherwise have merit, add functionality that was missing >>> before and don't regress, then lack of infrastructure to match up >>> bridge and driver isn't something I will care about too much yet. >>> Things are allowed to be in-progress. A missing abstraction for a 1:1 >>> relationship is fine. >> >> This is not just one-bridge, one-user. This is about users of Exynos DRM >> we already have in-tree, such as Trats, Trats2 or Arndale, that the DRM >> bridge infrastructure could be used on and finally allowing to have >> display support on them. Of course you could merge this as is and >> then let someone else completely rewrite it (most likely in the same >> release cycle), but since it's not really much more work, I don't >> think there is any sense. > > well, I'm not quite sure where I there is a pending complete > re-write.. it looks like the hard ptn3460 dependency is just a few > lines in one function. Otherwise I'd agree with you. > > (and even the patch that touches the code calling ptn3460_init() is > just moving it around from what I see) > >> Moreover, let's stick to modern kernel driver coding standards. I don't >> think that "I want this patchset merged so badly" is really a good excuse >> to get around it. After all, there would be no GKH's staging tree, if >> nobody cared about quality in mainline. > > And with my quality hat on, I could say that I'm not too fond of > unused (or 1:1 client to user) abstractions. That is something that > should be introduced as we merge our 2nd or 3rd bridge. > > BR, > -R > >> Best regards, >> Tomasz >> > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #15 from sotiris papadimitriou --- $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:DynPwr::01:05.0 1:DIS: :DynPwr::02:00.0 The DynPwr should exist on both cards or only the dGPU? Does runpm extinguished and the two cards and the computer freezes? -- 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/20131130/acc12887/attachment-0001.html>
[Bug 66201] New: AMD atombios stuck
https://bugzilla.kernel.org/show_bug.cgi?id=66201 Bug ID: 66201 Summary: AMD atombios stuck Product: Drivers Version: 2.5 Kernel Version: 3.13rc2 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: russianneuromancer at ya.ru Regression: No Created attachment 116861 --> https://bugzilla.kernel.org/attachment.cgi?id=116861&action=edit dmesg Please look into attached dmesg. 3.13rc1 didn't tested. 3.12 boot fine. runpm disabled. ~$ lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6620G] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon: fix VGT_GS_INSTANCE_CNT register
this register was incorrect for evergreen and cayman. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_drv.h | 3 ++- drivers/gpu/drm/radeon/reg_srcs/cayman| 2 +- drivers/gpu/drm/radeon/reg_srcs/evergreen | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h index b369d42..e1082be 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.h +++ b/drivers/gpu/drm/radeon/radeon_drv.h @@ -108,9 +108,10 @@ * 1.31- Add support for num Z pipes from GET_PARAM * 1.32- fixes for rv740 setup * 1.33- Add r6xx/r7xx const buffer support + * 1.34- fix evergreen/cayman GS register */ #define DRIVER_MAJOR 1 -#define DRIVER_MINOR 33 +#define DRIVER_MINOR 34 #define DRIVER_PATCHLEVEL 0 /* The rest of the file is DEPRECATED! */ diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman b/drivers/gpu/drm/radeon/reg_srcs/cayman index a072fa8..af7a941 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/cayman +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman @@ -532,7 +532,7 @@ cayman 0x9400 0x00028B84 PA_SU_POLY_OFFSET_FRONT_OFFSET 0x00028B88 PA_SU_POLY_OFFSET_BACK_SCALE 0x00028B8C PA_SU_POLY_OFFSET_BACK_OFFSET -0x00028B74 VGT_GS_INSTANCE_CNT +0x00028B90 VGT_GS_INSTANCE_CNT 0x00028BD4 PA_SC_CENTROID_PRIORITY_0 0x00028BD8 PA_SC_CENTROID_PRIORITY_1 0x00028BDC PA_SC_LINE_CNTL diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen b/drivers/gpu/drm/radeon/reg_srcs/evergreen index b912a37..e19ef0e 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen @@ -545,7 +545,7 @@ evergreen 0x9400 0x00028B84 PA_SU_POLY_OFFSET_FRONT_OFFSET 0x00028B88 PA_SU_POLY_OFFSET_BACK_SCALE 0x00028B8C PA_SU_POLY_OFFSET_BACK_OFFSET -0x00028B74 VGT_GS_INSTANCE_CNT +0x00028B90 VGT_GS_INSTANCE_CNT 0x00028C00 PA_SC_LINE_CNTL 0x00028C08 PA_SU_VTX_CNTL 0x00028C0C PA_CL_GB_VERT_CLIP_ADJ -- 1.8.4.2
[PATCH 13/19] drm: do not steal the display if we have a master
Hi
On Wed, Nov 27, 2013 at 9:24 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Sometimes we want to disable all the screens on a system, because that
> will allow the graphics card to be put into low-power states. The
> problem is that, for example, while all screens are disabled, if we
> get a hotplug interrupt, fbcon will decide to set a mode instead of
> keeping everything disabled, which will remove us from our low power
> states.
>
> Let's assume that if there's a DRM master, it will be able to do
> whatever is appropriate when we get the hotplug.
>
> This problem can be reproduced by the runtime PM test program from
> intel-gpu-tools: we disable all the screens so the graphics device can
> be put into D3, then something triggers a hotplug interrupt, fbcon
> sets a mode and breaks our test suite. The problem can be reproduced
> more easily by the "i2c" subtest.
>
> Other approaches considered for the problem:
> - Return "false" if "bound == 0" and the caller of
> drm_fb_helper_is_bound is a hotplug handler. This would break
> the case where the machine boots with no outputs connected, then
> the user plugs a monitor.
> - Add a new IOCTL to force fbcon to not set modes. This would keep
> all the current applications behaving the same, but adding a new
> IOCTL is not always the greatest idea.
> - Return false only if "dev->primary->master && bound == 0". This
> was my first implementation, but Chris suggested we should do
> the check irrespective of the "bound" variable.
>
> Thanks to Daniel Vetter for the investigation, ideas and the
> implementation of the hotplug alternative.
>
> v2: - Do the check first, irrespective of "bound".
> - Cc dri-devel
Thank god all that will get dropped with CONFIG_FB=n. Anyhow:
Reviewed-by: David Herrmann
Thanks
David
> Cc: dri-devel at lists.freedesktop.org
> Credits-to: Daniel Vetter
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/drm_fb_helper.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0a19401..98a0363 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -359,6 +359,11 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper
> *fb_helper)
> struct drm_crtc *crtc;
> int bound = 0, crtcs_bound = 0;
>
> + /* Sometimes user space wants everything disabled, so don't steal the
> +* display if there's a master. */
> + if (dev->primary->master)
> + return false;
> +
> list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> if (crtc->fb)
> crtcs_bound++;
> @@ -368,6 +373,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper
> *fb_helper)
>
> if (bound < crtcs_bound)
> return false;
> +
> return true;
> }
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #3 from Christoph Haag --- Created attachment 116871 --> https://bugzilla.kernel.org/attachment.cgi?id=116871&action=edit dmesg from 3.13-rc2 with rmmod radeon in line 2095 Having enough time to test everything would be nice. But in the meantime I have only tested 3.13-rc2. With defaults the issues are still there (I have not yet checked whether mentioned commits made it into rc2). Now I have some more messsages in dmesg after rmmod'ing radeon. This time it didn't hang after all that, but rebooting didn't work for some reason. Maybe it's just me but I'd like to have proper unloading to have the option to switch between radeon and fglrx without rebooting. :) Anyway with runpm=0 I don't get any errors so dpm does really work fine. On an unrelated note: WOW, has radeonsi improved in performance! Much better than fglrx with "official" hybrid support in some applications at least. Unfortunately using runpm=0 and using vgaswitcheroo manually is not a viable workaround because of https://bugzilla.kernel.org/show_bug.cgi?id=51381 But with runpm=0 there still is a similar (?) problem when rmmod'ing radeon: [ 1897.087151] [drm] radeon: finishing device. [ 1897.518615] [ cut here ] [ 1897.518634] WARNING: CPU: 4 PID: 2539 at drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2e/0x30 [drm]() [ 1897.518635] Memory manager not clean during takedown. [ 1897.518636] Modules linked in: bnep bluetooth iTCO_wdt iTCO_vendor_support arc4 iwldvm snd_hda_codec_hdmi mac80211 snd_hda_codec_realtek joydev x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crct10dif_common crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_hda_intel microcode snd_hda_codec iwlwifi snd_hwdep psmouse cfg80211 snd_pcm serio_raw pcspkr snd_page_alloc radeon(-) rtsx_pci_ms r8169 snd_timer memstick rfkill lpc_ich mii snd i2c_i801 soundcore ttm wmi thermal mei_me mei shpchp processor battery ac evdev nfs lockd sunrpc fscache fuse ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod hid_generic usbhid hid rtsx_pci_sdmmc mmc_core ahci i915 libahci crc32c_intel i2c_algo_bit libata intel_agp firewire_ohci intel_gtt [ 1897.518659] firewire_core crc_itu_t drm_kms_helper ehci_pci ehci_hcd xhci_hcd scsi_mod rtsx_pci drm usbcore i2c_core usb_common video button [ 1897.518665] CPU: 4 PID: 2539 Comm: rmmod Not tainted 3.13.0-1-mainline #1 [ 1897.518666] Hardware name: CLEVO P170EM/P170EM, BIOS 4.6.5 08/22/2012 [ 1897.518667] 0009 8807d4b47c20 814f5570 8807d4b47c68 [ 1897.518669] 8807d4b47c58 81061bad 8807fef616c0 8807fef61768 [ 1897.518671] 8808029a47b0 01ce5090 8807d4b47cb8 [ 1897.518673] Call Trace: [ 1897.518677] [] dump_stack+0x4d/0x6f [ 1897.518681] [] warn_slowpath_common+0x7d/0xa0 [ 1897.518683] [] warn_slowpath_fmt+0x4c/0x50 [ 1897.518688] [] ? ttm_bo_man_takedown+0x48/0x70 [ttm] [ 1897.518693] [] drm_mm_takedown+0x2e/0x30 [drm] [ 1897.518696] [] ttm_bo_man_takedown+0x38/0x70 [ttm] [ 1897.518699] [] ttm_bo_clean_mm+0x49/0x80 [ttm] [ 1897.518709] [] radeon_ttm_fini+0xbd/0x190 [radeon] [ 1897.518716] [] radeon_bo_fini+0x12/0x20 [radeon] [ 1897.518727] [] si_fini+0xc1/0x100 [radeon] [ 1897.518733] [] radeon_device_fini+0x3e/0x120 [radeon] [ 1897.518739] [] radeon_driver_unload_kms+0x4e/0x70 [radeon] [ 1897.518744] [] drm_dev_unregister+0x2c/0xe0 [drm] [ 1897.518749] [] drm_put_dev+0x3b/0x70 [drm] [ 1897.518754] [] radeon_pci_remove+0x1d/0x20 [radeon] [ 1897.518756] [] pci_device_remove+0x3b/0xb0 [ 1897.518759] [] __device_release_driver+0x7f/0xf0 [ 1897.518761] [] driver_detach+0xb8/0xc0 [ 1897.518763] [] bus_remove_driver+0x55/0xd0 [ 1897.518765] [] driver_unregister+0x2c/0x50 [ 1897.518767] [] pci_unregister_driver+0x29/0x90 [ 1897.518772] [] drm_pci_exit+0x98/0xa0 [drm] [ 1897.518778] [] radeon_exit+0x17/0x1e [radeon] [ 1897.518780] [] SyS_delete_module+0x172/0x240 [ 1897.518783] [] ? do_notify_resume+0x8c/0xa0 [ 1897.518785] [] system_call_fastpath+0x1a/0x1f [ 1897.518786] ---[ end trace ba1fe37dd4719714 ]--- [ 1897.518790] [TTM] Finalizing pool allocator [ 1897.518793] [TTM] Finalizing DMA pool allocator [ 1897.518797] [ cut here ] [ 1897.518799] WARNING: CPU: 4 PID: 2539 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:534 ttm_dma_free_pool+0x12b/0x130 [ttm]() [ 1897.518800] Modules linked in: bnep bluetooth iTCO_wdt iTCO_vendor_support arc4 iwldvm snd_hda_codec_hdmi mac80211 snd_hda_codec_realtek joydev x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crct10dif_common crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_hda_intel microcode snd_hda_codec iwlwifi snd_hwdep psmouse cfg80211 snd_pcm serio_raw pcspkr snd_page_alloc radeon(-) rtsx_pci_ms r8169 snd_ti
[PATCH v3 31/32] drm/exynos: Move lvds bridge discovery into DP driver
Hi Inki, On Saturday 30 of November 2013 14:18:08 Inki Dae wrote: > Hi Tomasz, > > Thanks for review, You're welcome. > > 2013/11/30 Tomasz Figa : > > Hi Sean, > > > > On Tuesday 29 of October 2013 12:13:17 Sean Paul wrote: > >> This patch moves the lvds bridge discovery and connector pre-emption > >> code from exynos common code into the dp driver (since the bridge is > >> only applicable for dp). > >> > >> Signed-off-by: Sean Paul > >> --- > >> > >> Changes in v3: > >> - Added to the patchset > >> > >> drivers/gpu/drm/exynos/exynos_dp_core.c | 41 > >> > >> drivers/gpu/drm/exynos/exynos_drm_core.c | 41 > >> > >> 2 files changed, 41 insertions(+), 41 deletions(-) > >> > > > > Well, DRM bridge infrastructure is useful for more than just DP. Currently > > there are several platforms that could use it with DSI as well, e.g. > > In case that some board with DSI bus needs this LVDS bridge, the > bridge type would be MIPI-DSI to LVDS Display bridge. So I think > moving this lvds stuff into eDP driver is reasonable becasue the > normal DSI bus cannot use this LVDS bridge, and this bridge (eDP to > LVDS) would be for eDP bus. BTW, Sean, why not implementing this lvds > codes to eDP driver without previous related patch? that seems > unnecessary work. I don't mean this particular bridge chip, but rather the bridge binding infrastructure. Anyway, having such hacks just in the DP driver is better than in Exynos DRM core and since we don't use DP on our platforms it doesn't bother me that much. So, if you really insist, I'm okay with this, just place all the bridge related code in this driver already, as Inki suggests. > > > Trats, Trats2, Arndale. With a simple abstraction worth of one or at most > > two days of work, we could get something that would cover much more than > > just a single Chromebook. > > I also thought a better way is to use simple abstraction layer. But > the abstraction layer I thought was the case that lvds binding is done > in this lvds driver itself so drm connector should call some bridge > related functions of the abstraction layer. But it seems that other > maintainers don't agree to this way. :( > > Anyway, we can say the use of lvds bridge is dependent on board but > actually, the use of lvds bridge would be more dependent on bus device > or lcd panel attached to the board. So my opinion is to bind dt in the > bus or lcd panel drivers that need lvds bridge. If dt binding of lvds > bridge cannot be done itself, Sean's way is reasonable to me except > the unnecessary patch. Well, I don't see why DT bindings couldn't be made for this. We already have bindings for video-interfaces (the so called v4l2 bindings), bindings for the LVDS bridge itself would be mostly device-specific, although we even already have bindings for display timings. Anyway, if even DRM people don't care, why should I? Just do what you want as long as it doesn't break other hardware. Best regards, Tomasz
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #16 from Mike Lothian --- Switching back to airlied's drm-radeon-poweroff branch which is based on 3.11-rc3 (which doesn't show my radeon card as a provider) has the following in switcheroo 0:DIS: :DynOff::01:00.0 1:IGD:+:Pwr::00:02.0 and this is what is shows with runpm=0 but with this set I'm able to see my radeon card as a provider -- 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/20131130/5410935f/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #17 from Mike Lothian --- Created attachment 90020 --> https://bugs.freedesktop.org/attachment.cgi?id=90020&action=edit Dmesg from drm-fixes-3.12-radeon-poweroff This is the dmesg from adg5f's drm-fixes-3.12-radeon-poweroff branch when I do a switcheroo OFF then ON with runpm=0 -- 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/20131130/9a00332a/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #18 from Mike Lothian --- With runpm=1 on adg5f's drm-fixes-3.12-radeon-poweroff which is based on 3.11.0-rc7 I get the following in switcheroo 0:DIS: :DynOff::01:00.0 1:IGD:+:Pwr::00:02.0 It also lists providers and DRI_PRIME works great powering the card as and when I fire something up and shows this in switcheroo 0:DIS: :DynPwr::01:00.0 1:IGD:+:Pwr::00:02.0 -- 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/20131130/26b457f9/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #19 from Mike Lothian --- This is currently what's in switcheroo in 3.13-rc2 with runpm=1 0:IGD:+:Pwr::00:02.0 1:DIS: :DynPwr::01:00.0 Which seems to have a reversed order - the system keeps powering up the radeon card and powering down -- 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/20131130/469617c7/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #20 from Mike Lothian --- Created attachment 90021 --> https://bugs.freedesktop.org/attachment.cgi?id=90021&action=edit Dmesg from 3.13-rc2 -- 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/20131130/5b392ab4/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #21 from Mike Lothian --- I'm only seeing the intel provider out out xrandr --listproviders and the system keeps stuttering when the card is either powered up (looks like when it's printing the dpm tables) -- 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/20131130/f07f3c59/attachment.html>
[RFC patch v2] x86: Improve boot_vga/vga_default_device() for EFI
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to detect devices when boot_vga=0 which is the case
on some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
the dri device but then bails out with "no devices detected".
With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting sysfb/efifb
optional.
Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in x86's pci_fixup_video().
Notes:
- Other architectures with PCI GPU might need a similar fixup.
- If CONFIG_VGA_ARB is unset vga_default_device() is only available
as a stub that returns NULL, making this adjustment insufficient.
Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
Signed-off-by: Bruno Pr?mont
---
arch/x86/include/asm/vga.h | 6 --
arch/x86/pci/fixup.c | 21 +
drivers/video/efifb.c | 38 --
3 files changed, 21 insertions(+), 44 deletions(-)
diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
index 44282fb..c4b9dc2 100644
--- a/arch/x86/include/asm/vga.h
+++ b/arch/x86/include/asm/vga.h
@@ -17,10 +17,4 @@
#define vga_readb(x) (*(x))
#define vga_writeb(x, y) (*(y) = (x))
-#ifdef CONFIG_FB_EFI
-#define __ARCH_HAS_VGA_DEFAULT_DEVICE
-extern struct pci_dev *vga_default_device(void);
-extern void vga_set_default_device(struct pci_dev *pdev);
-#endif
-
#endif /* _ASM_X86_VGA_H */
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index f5809fa..440343e 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -323,6 +324,26 @@ static void pci_fixup_video(struct pci_dev *pdev)
struct pci_bus *bus;
u16 config;
+ if (!vga_default_device()) {
+ resource_size_t start, end;
+ int i;
+
+ for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ start = pci_resource_start(pdev, i);
+ end = pci_resource_end(pdev, i);
+
+ if (!start || !end)
+ continue;
+
+ if (screen_info.lfb_base >= start &&
+ (screen_info.lfb_base + screen_info.lfb_size) <
end)
+ vga_set_default_device(pdev);
+ }
+ }
+
/* Is VGA routed to us? */
bus = pdev->bus;
while (bus) {
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 7f9ff75..fb3fb50 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -19,8 +19,6 @@
static bool request_mem_succeeded = false;
-static struct pci_dev *default_vga;
-
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -85,18 +83,6 @@ static struct fb_ops efifb_ops = {
.fb_imageblit = cfb_imageblit,
};
-struct pci_dev *vga_default_device(void)
-{
- return default_vga;
-}
-
-EXPORT_SYMBOL_GPL(vga_default_device);
-
-void vga_set_default_device(struct pci_dev *pdev)
-{
- default_vga = pdev;
-}
-
static int efifb_setup(char *options)
{
char *this_opt;
@@ -127,30 +113,6 @@ static int efifb_setup(char *options)
}
}
- for_each_pci_dev(dev) {
- int i;
-
- if ((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
- continue;
-
- for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
- resource_size_t start, end;
-
- if (!(pci_resource_flags(dev, i) & IORESOURCE_MEM))
- continue;
-
- start = pci_resource_start(dev, i);
- end = pci_resource_end(dev, i);
-
- if (!start || !end)
- continue;
-
- if (screen_info.lfb_base >= start &&
- (screen_info.lfb_base + screen_info.lfb_size) < end)
- default_vga = dev;
- }
- }
-
return 0;
}
[i915] BUG: Bad page state in process Xorg
On Sat, Nov 30, 2013 at 3:33 AM, Thomas Meyer wrote:
> Am Montag, den 25.11.2013, 08:23 -0500 schrieb Rob Clark:
>> oh, hmm.. are you importing buffers from i915? It looks like this part:
>
> My computer has an i915 graphic card and I use an USB docking station,
> that has an unconnected UDL device inside.
>
>>
>> - if (obj->base.import_attach) {
>> - drm_free_large(obj->pages);
>> - obj->pages = NULL;
>> - return;
>> - }
>>
>> should not have been removed from udl_gem_put_pages()..
>
> Do you want me to test this? Can this please be fixed in the stable
> tree?
> I removed the UDL driver from my config for now, as I don't use it.
It would be nice if you could test that (I can send you a patch if you
prefer).. I don't actually have any UDL device to confirm. If this
fixes the problem, send the patch to stable as well should not be a
problem.
BR,
-R
> *
> best regards
> thomas
>
>>
>> BR,
>> -R
>>
>> On Mon, Nov 25, 2013 at 8:17 AM, wrote:
>> > Hi,
>> >
>> > It turns out that this seems to be a bug in udl DRM driver.
>> >
>> > I bisected the problem to this patch:
>> >
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=5dc9e1e87229cb786a5bb58ddd0d60fee6eb4641
>> >
>> > With kind regards
>> > Thomas
>> >
>> > Am 22.11.2013 17:18 schrieb Daniel Vetter :
>> >>
>> >> On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer wrote:
>> >> >> Am 22.11.2013 um 11:55 schrieb Daniel Vetter :
>> >> >>
>> >> >> On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie
>> >> >> wrote:
>> >> Hi,
>> >> >>>
>> >> >>> cc'ing mailing list,
>> >> >>>
>> >> >>> Daniel any ideas?
>> >> >>
>> >> >> Nope, not really :( And no ideas how to triage this further - if it
>> >> >> takes 9 days to hit it eventually we'll have a real hard time. Or does
>> >> >> this happen even after just a short X run?
>> >> >
>> >> > Seems to happen every time while stopping the x server. Also after a
>> >> > short run time.
>> >> >
>> >> > The current fedora 3.11 kernel doesn't show this bug. I'm using fedora
>> >> > 19, with a self compiled kernel.
>> >> >
>> >> > I did turn on config-debug-pagealloc but this didn't show any wrongness.
>> >>
>> >> In that case I think the bisect is the fastest way to insight - atm
>> >> I'm really at loss what could be wrong here.
>> >> -Daniel
>> >> --
>> >> Daniel Vetter
>> >> Software Engineer, Intel Corporation
>> >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On both v3.13-rc1 and v3.13-rc2 is see this at every boot and during every suspend and resume cycle: <4>[2.682468] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector+0x42/0x50 [i915]() <5>[2.682470] Modules linked in: i915(F+) ata_generic(F) pata_acpi(F) yenta_socket(F+) i2c_algo_bit(F) drm_kms_helper(F) tg3(F+) ptp(F) pps_core(F) drm(F) i2c_core(F) video(F) sunrpc(F) <5>[2.682489] CPU: 0 PID: 173 Comm: systemd-udevd Tainted: GF 3.13.0-0.rc2.1.local0.fc18.i686 #1 <5>[2.682492] Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <5>[2.682495] f54739f4 c09b66d2 f5473a24 c0449b14 c0b541a4 <5>[2.682502] 00ad f82c9524 26dc f8282692 f8282692 f555ed80 00061200 <5>[2.682509] f567c000 f5473a34 c0449b52 0009 f5473a40 f8282692 f5578800 <5>[2.682516] Call Trace: <5>[2.682528] [] dump_stack+0x41/0x52 <5>[2.682534] [] warn_slowpath_common+0x84/0xa0 <5>[2.682571] [] ? intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682607] [] ? intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682612] [] warn_slowpath_null+0x22/0x30 <5>[2.682648] [] intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682689] [] intel_panel_disable_backlight+0x21/0x160 [i915] <5>[2.682725] [] intel_disable_lvds+0x41/0x160 [i915] <5>[2.682760] [] i9xx_crtc_disable+0x200/0x2c0 [i915] <5>[2.682802] [] ? gen4_read32+0x31/0x90 [i915] <5>[2.682839] [] intel_modeset_setup_hw_state+0x92e/0xb00 [i915] <5>[2.682844] [] ? power_down+0x8c/0x8d <5>[2.682884] [] ? gen4_write64+0xa0/0xa0 [i915] <5>[2.682920] [] intel_modeset_gem_init+0x20/0x30 [i915] <5>[2.682950] [] i915_driver_load+0xb53/0xdd0 [i915] <5>[2.682978] [] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] <5>[2.683003] [] drm_dev_register+0x8c/0x1a0 [drm] <5>[2.683043] [] drm_get_pci_dev+0x85/0x130 [drm] <5>[2.683050] [] ? sysfs_do_create_link_sd.isra.3+0xa8/0x1c0 <5>[2.683057] [] ? notifier_call_chain+0x43/0x60 <5>[2.683086] [] i915_pci_probe+0x3a/0x80 [i915] <5>[2.683093] [] pci_device_probe+0x79/0xc0 <5>[2.683097] [] ? sysfs_create_link+0x25/0x40 <5>[2.683104] [] driver_probe_device+0x79/0x360 <5>[2.683108] [] ? pci_match_device+0x9e/0xb0 <5>[2.683113] [] __driver_attach+0x91/0xa0 <5>[2.683117] [] ? driver_probe_device+0x360/0x360 <5>[2.683121] [] bus_for_each_dev+0x42/0x80 <5>[2.683125] [] driver_attach+0x1e/0x20 <5>[2.683130] [] ? driver_probe_device+0x360/0x360 <5>[2.683134] [] bus_add_driver+0xec/0x210 <5>[2.683138] [] driver_register+0x59/0xe0 <5>[2.683142] [] ? 0xf7fb1fff <5>[2.683147] [] __pci_register_driver+0x33/0x40 <5>[2.683150] [] ? 0xf7fb1fff <5>[2.683166] [] drm_pci_init+0xfd/0x110 [drm] <5>[2.683170] [] ? 0xf7fb1fff <5>[2.683198] [] i915_init+0x5e/0x60 [i915] <5>[2.683203] [] do_one_initcall+0xda/0x1a0 <5>[2.683206] [] ? 0xf7fb1fff <5>[2.683211] [] ? __add_event_to_tracers+0x21/0x30 <5>[2.683215] [] ? 0xf7fb1fff <5>[2.683221] [] ? set_memory_ro+0x37/0x40 <5>[2.683228] [] load_module+0x1abd/0x2390 <5>[2.683235] [] SyS_init_module+0xa7/0x110 <5>[2.683242] [] ? vm_mmap_pgoff+0x8b/0xb0 <5>[2.683248] [] sysenter_do_call+0x12/0x28 Feel free to prod for further details. Paul Bolle
i915: pipe state still does not match
On Sat, Nov 30, 2013 at 05:31:34PM +0100, Jan Engelhardt wrote: > > On Friday 2013-11-29 11:48, Chris Wilson wrote: > >> What I could collect so far: > > > >Thanks, I broke the handling of cropped XvImages along the fast paths. > >It should be fixed by: > > > >commit fd007d9d465b9b3ddbbaf769931ec921a6f5ecb8 > >Author: Chris Wilson > >Date: Thu Nov 28 21:13:33 2013 + > > > >sna/video: Correct handling of cropped images along packed fast path > > I didn't manage to crash X within an hour, so that's commit is looking > good. > > The kernel error message for i915 pipe state however still appears - > namely, whenever the X server is terminating, including "reasonably > proper" terminations induced with sending SIGTERM to the X process. > Could it be that the i915 module does not handle sudden shutdowns > (which however can occur at any time) of the /dev/dri/cardN file > descriptor well enough? I'd say it was just the KMS transition from the X mode to the fbcon mode that triggers the inconsistent state warning. The warning is just that the hardware state after the mode change does not match our expectations - often this is a result of a buggy state readback, but sometimes it does indicate a more severe bug in our mode programming. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=64801 --- Comment #11 from aaannz at gmail.com --- Created attachment 90044 --> https://bugs.freedesktop.org/attachment.cgi?id=90044&action=edit dmesg output I too am seeing this. Particularly in games Euro Truck Simulator 2 and X3 franchise. Graphical corruption is obvious. dmesg output attached. My specs: CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GPU: AMD HD6850 (Barts) RAM: 8GB > cat /etc/os-release NAME=openSUSE VERSION="13.1 (Bottle)" VERSION_ID="13.1" PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)" ID=opensuse ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:opensuse:13.1" BUG_REPORT_URL="https://bugs.opensuse.org"; HOME_URL="https://opensuse.org/"; ID_LIKE="suse" > uname -a Linux Cerberos 3.12.1-1.g999c17a-desktop #1 SMP PREEMPT Thu Nov 21 09:04:33 UTC 2013 (999c17a) x86_64 x86_64 x86_64 GNU/Linux > rpm -qa Mesa* Mesa-libglapi-devel-9.2.3-316.2.x86_64 Mesa-libGLESv2-devel-9.2.3-316.2.x86_64 Mesa-libEGL1-32bit-9.2.3-316.2.x86_64 Mesa-libGL1-9.2.3-316.2.x86_64 Mesa-libGL1-32bit-9.2.3-316.2.x86_64 Mesa-libGLESv2-2-32bit-9.2.3-316.2.x86_64 Mesa-libGL-devel-9.2.3-316.2.x86_64 Mesa-libGLESv1_CM-devel-9.2.3-316.2.x86_64 Mesa-libGLESv1_CM1-32bit-9.2.3-316.2.x86_64 Mesa-libGLESv1_CM1-9.2.3-316.2.x86_64 Mesa-libEGL1-9.2.3-316.2.x86_64 Mesa-libEGL-devel-9.2.3-316.2.x86_64 Mesa-libglapi0-9.2.3-316.2.x86_64 Mesa-9.2.3-316.2.x86_64 Mesa-libglapi0-32bit-9.2.3-316.2.x86_64 Mesa-demo-x-8.1.0-31.1.x86_64 Mesa-32bit-9.2.3-316.2.x86_64 Mesa-devel-9.2.3-316.2.x86_64 Mesa-libGLESv2-2-9.2.3-316.2.x86_64 -- 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/20131130/ad6e938d/attachment.html>
i915: pipe state still does not match
On Friday 2013-11-29 11:48, Chris Wilson wrote: >> What I could collect so far: > >Thanks, I broke the handling of cropped XvImages along the fast paths. >It should be fixed by: > >commit fd007d9d465b9b3ddbbaf769931ec921a6f5ecb8 >Author: Chris Wilson >Date: Thu Nov 28 21:13:33 2013 + > >sna/video: Correct handling of cropped images along packed fast path I didn't manage to crash X within an hour, so that's commit is looking good. The kernel error message for i915 pipe state however still appears - namely, whenever the X server is terminating, including "reasonably proper" terminations induced with sending SIGTERM to the X process. Could it be that the i915 module does not handle sudden shutdowns (which however can occur at any time) of the /dev/dri/cardN file descriptor well enough?
[i915] BUG: Bad page state in process Xorg
Am Montag, den 25.11.2013, 08:23 -0500 schrieb Rob Clark:
> oh, hmm.. are you importing buffers from i915? It looks like this part:
My computer has an i915 graphic card and I use an USB docking station,
that has an unconnected UDL device inside.
>
> - if (obj->base.import_attach) {
> - drm_free_large(obj->pages);
> - obj->pages = NULL;
> - return;
> - }
>
> should not have been removed from udl_gem_put_pages()..
Do you want me to test this? Can this please be fixed in the stable
tree?
I removed the UDL driver from my config for now, as I don't use it.
*
best regards
thomas
>
> BR,
> -R
>
> On Mon, Nov 25, 2013 at 8:17 AM, wrote:
> > Hi,
> >
> > It turns out that this seems to be a bug in udl DRM driver.
> >
> > I bisected the problem to this patch:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=5dc9e1e87229cb786a5bb58ddd0d60fee6eb4641
> >
> > With kind regards
> > Thomas
> >
> > Am 22.11.2013 17:18 schrieb Daniel Vetter :
> >>
> >> On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer wrote:
> >> >> Am 22.11.2013 um 11:55 schrieb Daniel Vetter :
> >> >>
> >> >> On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie
> >> >> wrote:
> >> Hi,
> >> >>>
> >> >>> cc'ing mailing list,
> >> >>>
> >> >>> Daniel any ideas?
> >> >>
> >> >> Nope, not really :( And no ideas how to triage this further - if it
> >> >> takes 9 days to hit it eventually we'll have a real hard time. Or does
> >> >> this happen even after just a short X run?
> >> >
> >> > Seems to happen every time while stopping the x server. Also after a
> >> > short run time.
> >> >
> >> > The current fedora 3.11 kernel doesn't show this bug. I'm using fedora
> >> > 19, with a self compiled kernel.
> >> >
> >> > I did turn on config-debug-pagealloc but this didn't show any wrongness.
> >>
> >> In that case I think the bisect is the fastest way to insight - atm
> >> I'm really at loss what could be wrong here.
> >> -Daniel
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 00/14] drm: Some more vblank timestampi changes
On 29/11/13 14:36, Ville Syrj?l? wrote: > On Wed, Nov 06, 2013 at 01:46:41PM +1000, Dave Airlie wrote: >> On Wed, Oct 30, 2013 at 4:06 AM, wrote: >>> So I took another look at the vblank timestamping code, and got a bit >>> excited. The result is this patchset. >> >> I'd like to merge this, I was hoping Mario could ack it at least as it >> seems mostly sane to my eyes. > > So we missed that boat, but maybe we'll get the next one... > > Pinging Mario. Any chance you can take a look at this stuff at some > point? > I will, including testing. Hopefully within the coming week, but definitely safely before christmas. > Hmm. Do I have the wrong email addres for Mario? Adding the other one > too just to make sure... > Both work, but the tuebingen.mpg.de one will probably soon turn into a pure forward to the gmail one. -mario
