[Intel-gfx] backtrace with 3.9.0-rc4 on MBP retina
Just stuck 3.9.0-rc4 on my MBP today, got this throwing up. Dave. [3.482355] [drm] Memory usable by graphics device = 2048M [3.482381] i915 :00:02.0: setting latency timer to 64 [3.482768] sdhci-pci :03:00.1: SDHCI controller found [14e4:16bc] (rev 10) [3.482825] sdhci-pci :03:00.1: enabling device ( -> 0002) [3.512438] mmc0: SDHCI controller on PCI [:03:00.1] using ADMA [3.524138] i915 :00:02.0: irq 53 for MSI/MSI-X [3.524150] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [3.524151] [drm] Driver supports precise vblank timestamp query. [3.524158] i915 :00:02.0: Invalid ROM contents [3.524162] [drm] failed to find VBIOS tables [3.524486] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem [3.524488] vgaarb: transferring owner from PCI::00:02.0 to PCI::01:00.0 [3.557336] [drm] failed to retrieve link info, disabling eDP [3.557787] [ cut here ] [3.557805] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1132 ironlake_panel_vdd_off_sync+0xef/0x100 [i915]() [3.557806] Hardware name: MacBookPro10,1 [3.557807] Modules linked in: sdhci_pci sdhci mmc_core i915(+) nouveau(+) mxm_wmi wmi ttm i2c_algo_bit drm_kms_helper drm i2c_core video [3.557816] Pid: 172, comm: systemd-udevd Tainted: GW 3.9.0-rc4+ #34 [3.557817] Call Trace: [3.557822] [] warn_slowpath_common+0x7f/0xc0 [3.557825] [] warn_slowpath_null+0x1a/0x20 [3.557836] [] ironlake_panel_vdd_off_sync+0xef/0x100 [i915] [3.557846] [] intel_dp_encoder_destroy+0x64/0x70 [i915] [3.557856] [] intel_dp_init_connector+0xaa6/0xac0 [i915] [3.557864] [] ? drm_modeset_unlock_all+0x52/0x60 [drm] [3.557874] [] intel_dp_init+0x106/0x140 [i915] [3.557884] [] intel_modeset_init+0xbf9/0xea0 [i915] [3.557894] [] i915_driver_load+0xb81/0xe30 [i915] [3.557901] [] drm_get_pci_dev+0x186/0x2d0 [drm] [3.557904] [] ? trace_hardirqs_on+0xd/0x10 [3.557913] [] i915_pci_probe+0x3c/0x90 [i915] [3.557915] [] local_pci_probe+0x4b/0x80 [3.557918] [] pci_device_probe+0x111/0x120 [3.557921] [] driver_probe_device+0x8b/0x390 [3.557923] [] __driver_attach+0xab/0xb0 [3.557926] [] ? driver_probe_device+0x390/0x390 [3.557928] [] bus_for_each_dev+0x5d/0xa0 [3.557930] [] driver_attach+0x1e/0x20 [3.557933] [] bus_add_driver+0x121/0x2b0 [3.557935] [] ? 0xa0245fff [3.557937] [] driver_register+0x77/0x170 [3.557939] [] ? 0xa0245fff [3.557941] [] __pci_register_driver+0x64/0x70 [3.557946] [] drm_pci_init+0x11a/0x130 [drm] [3.557948] [] ? 0xa0245fff [3.557956] [] i915_init+0x66/0x68 [i915] [3.557959] [] do_one_initcall+0x12a/0x180 [3.557962] [] load_module+0x1c3e/0x27e0 [3.557964] [] ? ddebug_proc_open+0xd0/0xd0 [3.557967] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [3.557969] [] sys_init_module+0xd7/0x120 [3.557972] [] system_call_fastpath+0x16/0x1b [3.557973] ---[ end trace 6cad52bf765be3e1 ]--- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: HSW PM Frequency bits fix
On Tue, Feb 26, 2013 at 05:57:20PM -0300, Paulo Zanoni wrote: > Hi > > 2013/2/25 Rodrigo Vivi : > > According to HSW PM programming guide, frequency bits starts at > > 24 instead of 25 > > This looks incomplete. Please check all the cases where RPNSWREQ is > used, I think we need to fix them too. Also, according to the PM > programming guide, all the other RPNSWREQ bits are reserved/read-only, > but I still see our code trying to set some of these bits (even if > it's trying to set it to zero), so I guess that on Haswell all the > writes to RPNSWREQ should only contain the HSW_FREQUENCY macro, not > others. And for those other bits, we need to discover where did they > go. We really should get this, or some version of this patch committed sooner rather than later. If there is disagreement over the entire series, could you please extract the important part into an individual patch? [snip] -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: creating Haswell rc6 function
On Mon, Feb 25, 2013 at 08:13:38PM -0300, Rodrigo Vivi wrote: > Power management, in special RC6 enabling, differs across platforms. > This patch just split out enabling function for HSW. > > Signed-off-by: Rodrigo Vivi I'm not at all opposed to splitting out Haswell rps stuff, but can you confirm that we really need to? I suspect gen6 + HSW are mostly the same and many of the differences currently exist because our gen6 stuff is very stale. [snip] -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] regression: grass turns red
commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old' somehow breaks the colors when I play 'civilization I' under xdosemu. During the intro of the game something the colors get messed up. When the game begins the grass of the earth is red. Reverting the commit fixes the problem. -- Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes for 3.9
Hi Dave, Just three revert/disable by default patches, one of them cc: stable (since the offending commit was cc: stable, too). Cheers, Daniel The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7: Linux 3.9-rc4 (2013-03-23 16:52:44 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to b1289371fcd580b4c412e6d05c4cb8ac8d277239: Revert "drm/i915: write backlight harder" (2013-03-24 13:23:20 +0100) Daniel Vetter (2): Revert "drm/i915: set TRANSCODER_EDP even earlier" Revert "drm/i915: write backlight harder" Paulo Zanoni (1): drm/i915: don't disable the power well yet drivers/gpu/drm/i915/i915_drv.c |5 + drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/intel_display.c | 10 +- drivers/gpu/drm/i915/intel_panel.c | 13 + drivers/gpu/drm/i915/intel_pm.c |3 +++ 5 files changed, 19 insertions(+), 13 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Screen blanking when copying files to USB/SD-Card ??
I have tested with 3.8.4 and the issue seems solved, thanks for the help! -- F. Delente ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correct sandybrige overclocking
On Sun, Mar 24, 2013 at 12:56 AM, Ben Widawsky wrote: >> Apparently massive overclocking like that makes your system die >> prematurely in a crash. So 3.10 it is, imo. >> -Daniel > > It's like all overclocking I guess, we simply give the user an > opportunity to shoot themselves in the foot. Glad to hear it is actually > doing something though. > > I agree that 3.10 sounds right; I'm thinking we'll want a module > parameter or something as well, to prevent spurious bug reports. What do > you think? I think not having a module option is ok, I don't expect that the enthusiast boards required to adjust the limits are that common. So it shouldn't affect more than just a few users, and those it does affect should know what their doing. Module options after all don't prevent them from setting unstable rc6 options, either ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
