Re: Linux 6.3-rc3
On Wed, Mar 22, 2023 at 1:49 PM Kalle Valo wrote:
>
> Nathan Chancellor writes:
>
> > On Mon, Mar 20, 2023 at 11:26:17AM -0700, Linus Torvalds wrote:
> >> On Mon, Mar 20, 2023 at 11:05 AM Nathan Chancellor
> >> wrote:
> >> >
> >> > On the clang front, I am still seeing the following warning turned error
> >> > for arm64 allmodconfig at least:
> >> >
> >> > drivers/gpu/host1x/dev.c:520:6: error: variable 'syncpt_irq' is
> >> > uninitialized when used here [-Werror,-Wuninitialized]
> >> > if (syncpt_irq < 0)
> >> > ^~
> >>
> >> Hmm. I do my arm64 allmodconfig builds with gcc, and I'm surprised
> >> that gcc doesn't warn about this.
> >
> > Perhaps these would make doing allmodconfig builds with clang more
> > frequently less painful for you?
> >
> > https://lore.kernel.org/llvm/20230319235619.GA18547@dev-arch.thelio-3990X/
>
> Thank you, at least for me this is really helpful. I tried now clang for
> the first time but seeing a strange problem.
>
> I prefer to define the compiler in GNUmakefile so it's easy to change
> compilers and I don't need to remember the exact command line. So I have
> this in the top level GNUmakefile (all the rest commented out):
>
> LLVM=/opt/clang/llvm-16.0.0/bin/
>
Welcome to the LLVM/Clang world!
First try - First Cry...
In my build-environment I add (export) /path/to/llvm/bin to $PATH and
pass single CC LD AR etc. (what is substituted by LLVM=1):
make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld
Equivalent to:
make LLVM=1
I cannot comment on `make LLVM=/path/to/llvm/` and/or combinations
with `LLVM=1` as I have never used it
> If I run 'make oldconfig' it seems to use clang but after I run just
> 'make' it seems to switch back to the host GCC compiler and ask for GCC
> specific config questions again. Workaround for this seems to be adding
> 'export LLVM' to GNUmakefile, after that also 'make' uses clang as
> expected.
>
You have to pass `make LLVM=1` in any case... to `oldconfig` or when
adding any MAKEFLAGS like -j${number-of-available-cpus}.
Hope that helps.
Best regards,
-Sedat-
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/llvm.rst
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/llvm.rst#n52
[intel-gfx] How to determine supported HDMI versions of an Intel GPU
[ Please CC me I am not subscribed to any CCed mailing-lists ] Hi Daniel, I hope you are well. While searching for a new monitor I wanted to buy a miniHDMI->HDMI adapter or cable to connect it. My Samsung laptop has a Intel HD graphics 3000 GPU and a miniHDMI connector. Unfortunately, I have no idea how to get information about supported HDMI versions and or supported resolutions when there is *no* external monitor connected. root# xrandr --listmonitors Monitors: 1 0: +XWAYLAND0 1366/293x768/165+0+0 XWAYLAND0 root# egrep -i 'hdmi|snb' /var/log/Xorg.0.log 101:[81.251] (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) HD Graphics 3000 (SNB GT2) 105:[81.255] (II) modeset(0): Output HDMI-1 has no monitor section 176:[81.264] (II) modeset(0): EDID for output HDMI-1 180:[81.264] (II) modeset(0): Output HDMI-1 disconnected 337:[87.548] (II) config/udev: Adding input device HDA Intel PCH HDMI/DP,pcm=3 (/dev/input/event11) I am here on Linux v5.15.10 and using KDE/Wayland 5.23.4. Do you need further information? Thanks in advance. Regards, - Sedat -
Re: [PATCH] drm/amd/pm/swsmu: Avoid using structure_size uninitialized in smu_cmn_init_soft_gpu_metrics
On Thu, Feb 18, 2021 at 11:49 PM Nathan Chancellor wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning:
> variable 'structure_size' is used uninitialized whenever switch default
> is taken [-Wsometimes-uninitialized]
> default:
> ^~~
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:770:23: note:
> uninitialized use occurs here
> memset(header, 0xFF, structure_size);
> ^~
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:753:25: note:
> initialize the variable 'structure_size' to silence this warning
> uint16_t structure_size;
>^
> = 0
> 1 warning generated.
>
> Return in the default case, as the size of the header will not be known.
>
> Fixes: de4b7cd8cb87 ("drm/amd/pm/swsmu: unify the init soft gpu metrics
> function")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1304
> Signed-off-by: Nathan Chancellor
I fell over this today with Linux v5.11-10201-gc03c21ba6f4e.
Tested-by: Sedat Dilek # LLVM/Clang v13-git
- Sedat -
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> index bb620fdd4cd2..bcedd4d92e35 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> @@ -762,7 +762,7 @@ void smu_cmn_init_soft_gpu_metrics(void *table, uint8_t
> frev, uint8_t crev)
> structure_size = sizeof(struct gpu_metrics_v2_0);
> break;
> default:
> - break;
> + return;
> }
>
> #undef METRICS_VERSION
> --
> 2.30.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/20210218224849.5591-1-nathan%40kernel.org.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
On Fri, Aug 9, 2019 at 1:03 AM Nick Desaulniers wrote: > > On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote: > > > tglx just picked up 2 other patches of mine, bumping just in case he's > > > not picking up patches while on vacation. ;) > > > > I'm only half on vacation :) > > > > So I can pick it up. > > Thanks, will send half margaritas. > Sends some Turkish Cay. - Sedat -
Re: [PATCHv2 0/3] convert i915 to new mount API
On Mon, Aug 5, 2019 at 6:05 PM Sergey Senozhatsky wrote: > > Hello, > > Convert i915 to a new mount API and fix i915_gemfs_init() kernel Oops. > > It also appears that we need to EXPORTs put_filesystem(), so i915 > can properly put filesystem after it is done with kern_mount(). > > v2: > - export put_filesystem() [Chris] > - always put_filesystem() in i915_gemfs_init() [Chris] > - improve i915_gemfs_init() error message [Chris] > > Sergey Senozhatsky (3): > fs: export put_filesystem() > i915: convert to new mount API > i915: do not leak module ref counter > Fee free to add: Reported-by: Sedat Dilek [1] https://lore.kernel.org/lkml/CA+icZUXh068m8UFeHDXCKDi0YfL2Z=woony7j7djlqat1cz...@mail.gmail.com/ > drivers/gpu/drm/i915/gem/i915_gemfs.c | 33 +++ > fs/filesystems.c | 1 + > 2 files changed, 25 insertions(+), 9 deletions(-) > > -- > 2.22.0 >
Re: [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
On Wed, Jul 31, 2019 at 2:25 PM Sedat Dilek wrote:
>
> On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson wrote:
> >
> > Quoting Thomas Gleixner (2019-07-26 20:18:32)
> > > On Fri, 26 Jul 2019, Chris Wilson wrote:
> > > > Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > > > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> > > > >
> > > > > > Objtool reports:
> > > > > >
> > > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> > > > > > .altinstr_replacement+0x36: redundant UACCESS disable
> > > > > >
> > > > > > __copy_from_user() already does both STAC and CLAC, so the
> > > > > > user_access_end() in its error path adds an extra unnecessary CLAC.
> > > > > >
> > > > > > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page
> > > > > > fault exception case")
> > > > > > Reported-by: Thomas Gleixner
> > > > > > Reported-by: Sedat Dilek
> > > > > > Acked-by: Peter Zijlstra (Intel)
> > > > > > Tested-by: Nick Desaulniers
> > > > > > Tested-by: Sedat Dilek
> > > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/617
> > > > > > Signed-off-by: Josh Poimboeuf
> > > > >
> > > > > Reviewed-by: Thomas Gleixner
> > > >
> > > > Which tree do you plan to apply it to? I can put in drm-intel, and with
> > > > the fixes tag it will percolate through to 5.3 and beyond, but if you
> > > > want to apply it directly to squash the build warnings, feel free.
> > >
> > > It would be nice to get it into 5.3. I can route it linuxwards if you give
> > > an Acked-by, but I'm happy to hand it to you :)
> >
> > Acked-by: Chris Wilson
>
> Thomas did you take this through tip tree after Chris' ACK?
>
Hi,
Gentle ping...
Thomas and Chris: Will someone of you pick this up?
As "objtool: Improve UACCESS coverage" [1] went trough tip tree I
highly appreciate to do so with this one.
Thanks.
Regards,
- Sedat -
[1] https://git.kernel.org/linus/882a0db9d143e5e8dac54b96e83135bccd1f68d1
[2] https://github.com/ClangBuiltLinux/linux/issues/617
Re: [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson wrote:
>
> Quoting Thomas Gleixner (2019-07-26 20:18:32)
> > On Fri, 26 Jul 2019, Chris Wilson wrote:
> > > Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> > > >
> > > > > Objtool reports:
> > > > >
> > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> > > > > .altinstr_replacement+0x36: redundant UACCESS disable
> > > > >
> > > > > __copy_from_user() already does both STAC and CLAC, so the
> > > > > user_access_end() in its error path adds an extra unnecessary CLAC.
> > > > >
> > > > > Fixes: 0b2c8f8b6b0c ("i915: fix missing user_access_end() in page
> > > > > fault exception case")
> > > > > Reported-by: Thomas Gleixner
> > > > > Reported-by: Sedat Dilek
> > > > > Acked-by: Peter Zijlstra (Intel)
> > > > > Tested-by: Nick Desaulniers
> > > > > Tested-by: Sedat Dilek
> > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/617
> > > > > Signed-off-by: Josh Poimboeuf
> > > >
> > > > Reviewed-by: Thomas Gleixner
> > >
> > > Which tree do you plan to apply it to? I can put in drm-intel, and with
> > > the fixes tag it will percolate through to 5.3 and beyond, but if you
> > > want to apply it directly to squash the build warnings, feel free.
> >
> > It would be nice to get it into 5.3. I can route it linuxwards if you give
> > an Acked-by, but I'm happy to hand it to you :)
>
> Acked-by: Chris Wilson
Thomas did you take this through tip tree after Chris' ACK?
- Sedat -
linux-next: build failure after merge of the drm tree
On 7/15/16, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
> drivers/gpu/drm/i915/intel_opregion.c: In function
> 'intel_opregion_get_panel_type':
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared
> (first use in this function)
> if (IS_SKYLAKE(dev)) {
> ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
> if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
> #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
> ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
> if (IS_SKYLAKE(dev)) {
> ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared
> identifier is reported only once for each function it appears in
> if (IS_SKYLAKE(dev)) {
> ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
> if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
> #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
> ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
> if (IS_SKYLAKE(dev)) {
> ^
>
> Caused by commit
>
> 6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native
> drm_i915_private")
>
> interacting with commit
>
> aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
>
> from the drm-intel-fixes tree.
>
> I applied this merge fix patch:
>
> From: Stephen Rothwell
> Date: Fri, 15 Jul 2016 13:34:05 +1000
> Subject: [PATCH] drm/i915/opregion: fix up for argument change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 21f19641e33e..dcdb346b596c 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
>* vswing instead. Low vswing results in some display flickers, so
>* let's simply ignore the OpRegion panel type on SKL for now.
>*/
> - if (IS_SKYLAKE(dev)) {
> + if (IS_SKYLAKE(dev_priv)) {
> DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> return -ENODEV;
> }
> --
> 2.8.1
>
I fell over the same issue when testing drm-intel-nightly and sent a patch.
- Sedat -
https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html
[PATCH] drm: vblank: Use POSIX date for DRM_INFO output
Signed-off-by: Sedat Dilek
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 607f493ae801..682cd4b3ba10 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -361,7 +361,7 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
num_crtcs)
(unsigned long)vblank);
}
- DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
+ DRM_INFO("Supports vblank timestamp caching Rev 2 (20131021).\n");
/* Driver specific high-precision vblank timestamping supported? */
if (dev->driver->get_vblank_timestamp)
--
2.6.4
[regression] Re: [Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled
On Wed, Sep 23, 2015 at 9:18 AM, Daniel Vetter wrote: > Adding Jairo to track this regression. Hi, commit 721a09f7393de6c28a07516dccd654c6e995944a "drm/i915: Add primary plane to mask if it's visible" ...pending in drm-intel.git#drm-intel-fixes fixes the issue here. - sed@ - [1] http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a > -Daniel > > On Wed, Sep 23, 2015 at 08:23:04AM +0200, Sedat Dilek wrote: >> On Sun, Sep 13, 2015 at 9:06 AM, Sedat Dilek >> wrote: >> > On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek >> > wrote: >> >> [ TO INTEL DRM DRIVERS maintainers ] >> >> >> >> Hi, >> >> >> >> out of curiosity and to play with the new bindeb-pkg make-target I >> >> built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a) >> >> Debian-kernel packages. >> >> >> >> I see several bugs and call-traces. >> >> >> >> Two hit a warning in i915 (one snippet here, full dmesg-log and >> >> kernel-config are attached). >> >> >> >> [ 20.920943] [ cut here ] >> >> [ 20.920982] WARNING: CPU: 0 PID: 114 at >> >> drivers/gpu/drm/i915/intel_display.c:1377 >> >> assert_planes_disabled+0xe4/0x150 [i915]() >> >> [ 20.920983] plane A assertion failure, should be disabled but not >> >> [ 20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi >> >> snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel >> >> snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm >> >> joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage >> >> kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit >> >> drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth >> >> snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea >> >> snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device >> >> serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst >> >> mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii >> >> [ 20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted >> >> 4.2.0-10463.1-iniza-small #1 >> >> [ 20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD. >> >> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 >> >> [ 20.921033] Workqueue: events_unbound async_run_entry_fn >> >> [ 20.921037] a06a9d60 8800378af718 813df89b >> >> 8800378af760 >> >> [ 20.921039] 8800378af750 8107cdc6 8800c200 >> >> >> >> [ 20.921042] 8800bf90b000 8800bf90b000 >> >> 8800378af7b0 >> >> [ 20.921043] Call Trace: >> >> [ 20.921046] [] dump_stack+0x4b/0x70 >> >> [ 20.921050] [] warn_slowpath_common+0x86/0xc0 >> >> [ 20.921052] [] warn_slowpath_fmt+0x4c/0x50 >> >> [ 20.921081] [] assert_planes_disabled+0xe4/0x150 >> >> [i915] >> >> [ 20.921106] [] intel_disable_pipe+0x4f/0x2d0 [i915] >> >> [ 20.921129] [] ironlake_crtc_disable+0x85/0x7d0 >> >> [i915] >> >> [ 20.921151] [] ? >> >> intel_crtc_disable_planes+0xde/0xf0 [i915] >> >> [ 20.921176] [] intel_atomic_commit+0x108/0x1370 >> >> [i915] >> >> [ 20.921192] [] ? drm_atomic_check_only+0x1d7/0x5a0 >> >> [drm] >> >> [ 20.921205] [] ? >> >> drm_atomic_get_connector_state+0x49/0x110 [drm] >> >> [ 20.921216] [] drm_atomic_commit+0x37/0x60 [drm] >> >> [ 20.921223] [] >> >> drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper] >> >> [ 20.921234] [] >> >> drm_mode_set_config_internal+0x65/0x110 [drm] >> >> [ 20.921240] [] restore_fbdev_mode+0xbe/0xe0 >> >> [drm_kms_helper] >> >> [ 20.921246] [] >> >> drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper] >> >> [ 20.921251] [] drm_fb_helper_set_par+0x2d/0x50 >> >> [drm_kms_helper] >> >> [ 20.921280] [] intel_fbdev_set_par+0x1a/0x60 [i915] >> >> [ 20.921283] [] fbcon_init+0x53e/0x5d0 >> >> [ 20.921286] [] visual_init+0xca/0x130 >> >> [ 20.921289] [] do_bind_con_driver+0x167/0x3a0 >> >> [ 20.921292] [] do_take_over_console+0xac/0x1d0 >> >> [ 2
[Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled
On Sun, Sep 13, 2015 at 9:06 AM, Sedat Dilek wrote: > On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek wrote: >> [ TO INTEL DRM DRIVERS maintainers ] >> >> Hi, >> >> out of curiosity and to play with the new bindeb-pkg make-target I >> built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a) >> Debian-kernel packages. >> >> I see several bugs and call-traces. >> >> Two hit a warning in i915 (one snippet here, full dmesg-log and >> kernel-config are attached). >> >> [ 20.920943] [ cut here ] >> [ 20.920982] WARNING: CPU: 0 PID: 114 at >> drivers/gpu/drm/i915/intel_display.c:1377 >> assert_planes_disabled+0xe4/0x150 [i915]() >> [ 20.920983] plane A assertion failure, should be disabled but not >> [ 20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi >> snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel >> snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm >> joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage >> kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit >> drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth >> snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea >> snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device >> serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst >> mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii >> [ 20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted >> 4.2.0-10463.1-iniza-small #1 >> [ 20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD. >> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 >> [ 20.921033] Workqueue: events_unbound async_run_entry_fn >> [ 20.921037] a06a9d60 8800378af718 813df89b >> 8800378af760 >> [ 20.921039] 8800378af750 8107cdc6 8800c200 >> >> [ 20.921042] 8800bf90b000 8800bf90b000 >> 8800378af7b0 >> [ 20.921043] Call Trace: >> [ 20.921046] [] dump_stack+0x4b/0x70 >> [ 20.921050] [] warn_slowpath_common+0x86/0xc0 >> [ 20.921052] [] warn_slowpath_fmt+0x4c/0x50 >> [ 20.921081] [] assert_planes_disabled+0xe4/0x150 [i915] >> [ 20.921106] [] intel_disable_pipe+0x4f/0x2d0 [i915] >> [ 20.921129] [] ironlake_crtc_disable+0x85/0x7d0 [i915] >> [ 20.921151] [] ? >> intel_crtc_disable_planes+0xde/0xf0 [i915] >> [ 20.921176] [] intel_atomic_commit+0x108/0x1370 [i915] >> [ 20.921192] [] ? drm_atomic_check_only+0x1d7/0x5a0 >> [drm] >> [ 20.921205] [] ? >> drm_atomic_get_connector_state+0x49/0x110 [drm] >> [ 20.921216] [] drm_atomic_commit+0x37/0x60 [drm] >> [ 20.921223] [] >> drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper] >> [ 20.921234] [] >> drm_mode_set_config_internal+0x65/0x110 [drm] >> [ 20.921240] [] restore_fbdev_mode+0xbe/0xe0 >> [drm_kms_helper] >> [ 20.921246] [] >> drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper] >> [ 20.921251] [] drm_fb_helper_set_par+0x2d/0x50 >> [drm_kms_helper] >> [ 20.921280] [] intel_fbdev_set_par+0x1a/0x60 [i915] >> [ 20.921283] [] fbcon_init+0x53e/0x5d0 >> [ 20.921286] [] visual_init+0xca/0x130 >> [ 20.921289] [] do_bind_con_driver+0x167/0x3a0 >> [ 20.921292] [] do_take_over_console+0xac/0x1d0 >> [ 20.921294] [] do_fbcon_takeover+0x57/0xb0 >> [ 20.921296] [] fbcon_event_notify+0x752/0x860 >> [ 20.921299] [] ? >> __blocking_notifier_call_chain+0x35/0x70 >> [ 20.921301] [] notifier_call_chain+0x5d/0x80 >> [ 20.921304] [] __blocking_notifier_call_chain+0x4d/0x70 >> [ 20.921306] [] blocking_notifier_call_chain+0x16/0x20 >> [ 20.921308] [] fb_notifier_call_chain+0x1b/0x20 >> [ 20.921311] [] register_framebuffer+0x204/0x330 >> [ 20.921317] [] >> drm_fb_helper_initial_config+0x234/0x3b0 [drm_kms_helper] >> [ 20.921344] [] intel_fbdev_initial_config+0x1b/0x20 >> [i915] >> [ 20.921346] [] async_run_entry_fn+0x37/0xe0 >> [ 20.921349] [] process_one_work+0x1e1/0x620 >> [ 20.921352] [] ? process_one_work+0x156/0x620 >> [ 20.921353] [] worker_thread+0x69/0x480 >> [ 20.921355] [] ? cancel_delayed_work_sync+0x20/0x20 >> [ 20.921357] [] kthread+0x10a/0x120 >> [ 20.921360] [] ? kthread_create_on_node+0x200/0x200 >> [ 20.921364] [] ret_from_fork+0x3f/0x70 >> [ 20.921366] [] ? kthread_create_on_node+0x200/0x200 >> [ 20.921367] ---[ end
[Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled
On Wed, Sep 9, 2015 at 4:42 AM, Sedat Dilek wrote: > [ TO INTEL DRM DRIVERS maintainers ] > > Hi, > > out of curiosity and to play with the new bindeb-pkg make-target I > built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a) > Debian-kernel packages. > > I see several bugs and call-traces. > > Two hit a warning in i915 (one snippet here, full dmesg-log and > kernel-config are attached). > > [ 20.920943] [ cut here ] > [ 20.920982] WARNING: CPU: 0 PID: 114 at > drivers/gpu/drm/i915/intel_display.c:1377 > assert_planes_disabled+0xe4/0x150 [i915]() > [ 20.920983] plane A assertion failure, should be disabled but not > [ 20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi > snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel > snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm > joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage > kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit > drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth > snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea > snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device > serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst > mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii > [ 20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted > 4.2.0-10463.1-iniza-small #1 > [ 20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD. > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 > [ 20.921033] Workqueue: events_unbound async_run_entry_fn > [ 20.921037] a06a9d60 8800378af718 813df89b > 8800378af760 > [ 20.921039] 8800378af750 8107cdc6 8800c200 > > [ 20.921042] 8800bf90b000 8800bf90b000 > 8800378af7b0 > [ 20.921043] Call Trace: > [ 20.921046] [] dump_stack+0x4b/0x70 > [ 20.921050] [] warn_slowpath_common+0x86/0xc0 > [ 20.921052] [] warn_slowpath_fmt+0x4c/0x50 > [ 20.921081] [] assert_planes_disabled+0xe4/0x150 [i915] > [ 20.921106] [] intel_disable_pipe+0x4f/0x2d0 [i915] > [ 20.921129] [] ironlake_crtc_disable+0x85/0x7d0 [i915] > [ 20.921151] [] ? > intel_crtc_disable_planes+0xde/0xf0 [i915] > [ 20.921176] [] intel_atomic_commit+0x108/0x1370 [i915] > [ 20.921192] [] ? drm_atomic_check_only+0x1d7/0x5a0 [drm] > [ 20.921205] [] ? > drm_atomic_get_connector_state+0x49/0x110 [drm] > [ 20.921216] [] drm_atomic_commit+0x37/0x60 [drm] > [ 20.921223] [] > drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper] > [ 20.921234] [] > drm_mode_set_config_internal+0x65/0x110 [drm] > [ 20.921240] [] restore_fbdev_mode+0xbe/0xe0 > [drm_kms_helper] > [ 20.921246] [] > drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper] > [ 20.921251] [] drm_fb_helper_set_par+0x2d/0x50 > [drm_kms_helper] > [ 20.921280] [] intel_fbdev_set_par+0x1a/0x60 [i915] > [ 20.921283] [] fbcon_init+0x53e/0x5d0 > [ 20.921286] [] visual_init+0xca/0x130 > [ 20.921289] [] do_bind_con_driver+0x167/0x3a0 > [ 20.921292] [] do_take_over_console+0xac/0x1d0 > [ 20.921294] [] do_fbcon_takeover+0x57/0xb0 > [ 20.921296] [] fbcon_event_notify+0x752/0x860 > [ 20.921299] [] ? > __blocking_notifier_call_chain+0x35/0x70 > [ 20.921301] [] notifier_call_chain+0x5d/0x80 > [ 20.921304] [] __blocking_notifier_call_chain+0x4d/0x70 > [ 20.921306] [] blocking_notifier_call_chain+0x16/0x20 > [ 20.921308] [] fb_notifier_call_chain+0x1b/0x20 > [ 20.921311] [] register_framebuffer+0x204/0x330 > [ 20.921317] [] > drm_fb_helper_initial_config+0x234/0x3b0 [drm_kms_helper] > [ 20.921344] [] intel_fbdev_initial_config+0x1b/0x20 > [i915] > [ 20.921346] [] async_run_entry_fn+0x37/0xe0 > [ 20.921349] [] process_one_work+0x1e1/0x620 > [ 20.921352] [] ? process_one_work+0x156/0x620 > [ 20.921353] [] worker_thread+0x69/0x480 > [ 20.921355] [] ? cancel_delayed_work_sync+0x20/0x20 > [ 20.921357] [] kthread+0x10a/0x120 > [ 20.921360] [] ? kthread_create_on_node+0x200/0x200 > [ 20.921364] [] ret_from_fork+0x3f/0x70 > [ 20.921366] [] ? kthread_create_on_node+0x200/0x200 > [ 20.921367] ---[ end trace 85fce5c152ff4528 ]--- > > Some intelgfx hardware infos (see attached Xorg.0.log)... > > [27.487] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD > Graphics 3000 > [27.565] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) > backend > > Please have a look at it. > > If this is a known issue, please let me know and kindly point me to a > patch (patchwork preferred) or commit-id in drm-intel Git. > ( Sorry, I have not checked any mailing-lists or patchwork. ) > > If you need more infos, logs and/or debug material please let me know > and give clear instructions (especially for debugging). > > I still see this issue with Linux v4.3-rc1. - Sedat -
[Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled
[ TO INTEL DRM DRIVERS maintainers ] Hi, out of curiosity and to play with the new bindeb-pkg make-target I built pre-v4.3-rc1 (git-describe says v4.2-10463-g9a9952bbd76a) Debian-kernel packages. I see several bugs and call-traces. Two hit a warning in i915 (one snippet here, full dmesg-log and kernel-config are attached). [ 20.920943] [ cut here ] [ 20.920982] WARNING: CPU: 0 PID: 114 at drivers/gpu/drm/i915/intel_display.c:1377 assert_planes_disabled+0xe4/0x150 [i915]() [ 20.920983] plane A assertion failure, should be disabled but not [ 20.921023] Modules linked in: i915 mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic uvcvideo snd_hda_intel snd_hda_codec videobuf2_vmalloc videobuf2_memops videobuf2_core rfcomm joydev bnep v4l2_common snd_hwdep iwlwifi videodev usb_storage kvm_intel snd_hda_core parport_pc cfg80211 btusb i2c_algo_bit drm_kms_helper ppdev btrtl btbcm snd_pcm btintel kvm bluetooth snd_seq_midi psmouse snd_seq_midi_event snd_rawmidi syscopyarea snd_seq sysfillrect sysimgblt fb_sys_fops drm snd_timer snd_seq_device serio_raw samsung_laptop snd lpc_ich video soundcore wmi intel_rst mac_hid lp parport binfmt_misc hid_generic usbhid hid r8169 mii [ 20.921026] CPU: 0 PID: 114 Comm: kworker/u16:5 Not tainted 4.2.0-10463.1-iniza-small #1 [ 20.921027] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 20.921033] Workqueue: events_unbound async_run_entry_fn [ 20.921037] a06a9d60 8800378af718 813df89b 8800378af760 [ 20.921039] 8800378af750 8107cdc6 8800c200 [ 20.921042] 8800bf90b000 8800bf90b000 8800378af7b0 [ 20.921043] Call Trace: [ 20.921046] [] dump_stack+0x4b/0x70 [ 20.921050] [] warn_slowpath_common+0x86/0xc0 [ 20.921052] [] warn_slowpath_fmt+0x4c/0x50 [ 20.921081] [] assert_planes_disabled+0xe4/0x150 [i915] [ 20.921106] [] intel_disable_pipe+0x4f/0x2d0 [i915] [ 20.921129] [] ironlake_crtc_disable+0x85/0x7d0 [i915] [ 20.921151] [] ? intel_crtc_disable_planes+0xde/0xf0 [i915] [ 20.921176] [] intel_atomic_commit+0x108/0x1370 [i915] [ 20.921192] [] ? drm_atomic_check_only+0x1d7/0x5a0 [drm] [ 20.921205] [] ? drm_atomic_get_connector_state+0x49/0x110 [drm] [ 20.921216] [] drm_atomic_commit+0x37/0x60 [drm] [ 20.921223] [] drm_atomic_helper_set_config+0x1ca/0x430 [drm_kms_helper] [ 20.921234] [] drm_mode_set_config_internal+0x65/0x110 [drm] [ 20.921240] [] restore_fbdev_mode+0xbe/0xe0 [drm_kms_helper] [ 20.921246] [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper] [ 20.921251] [] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [ 20.921280] [] intel_fbdev_set_par+0x1a/0x60 [i915] [ 20.921283] [] fbcon_init+0x53e/0x5d0 [ 20.921286] [] visual_init+0xca/0x130 [ 20.921289] [] do_bind_con_driver+0x167/0x3a0 [ 20.921292] [] do_take_over_console+0xac/0x1d0 [ 20.921294] [] do_fbcon_takeover+0x57/0xb0 [ 20.921296] [] fbcon_event_notify+0x752/0x860 [ 20.921299] [] ? __blocking_notifier_call_chain+0x35/0x70 [ 20.921301] [] notifier_call_chain+0x5d/0x80 [ 20.921304] [] __blocking_notifier_call_chain+0x4d/0x70 [ 20.921306] [] blocking_notifier_call_chain+0x16/0x20 [ 20.921308] [] fb_notifier_call_chain+0x1b/0x20 [ 20.921311] [] register_framebuffer+0x204/0x330 [ 20.921317] [] drm_fb_helper_initial_config+0x234/0x3b0 [drm_kms_helper] [ 20.921344] [] intel_fbdev_initial_config+0x1b/0x20 [i915] [ 20.921346] [] async_run_entry_fn+0x37/0xe0 [ 20.921349] [] process_one_work+0x1e1/0x620 [ 20.921352] [] ? process_one_work+0x156/0x620 [ 20.921353] [] worker_thread+0x69/0x480 [ 20.921355] [] ? cancel_delayed_work_sync+0x20/0x20 [ 20.921357] [] kthread+0x10a/0x120 [ 20.921360] [] ? kthread_create_on_node+0x200/0x200 [ 20.921364] [] ret_from_fork+0x3f/0x70 [ 20.921366] [] ? kthread_create_on_node+0x200/0x200 [ 20.921367] ---[ end trace 85fce5c152ff4528 ]--- Some intelgfx hardware infos (see attached Xorg.0.log)... [27.487] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 [27.565] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend Please have a look at it. If this is a known issue, please let me know and kindly point me to a patch (patchwork preferred) or commit-id in drm-intel Git. ( Sorry, I have not checked any mailing-lists or patchwork. ) If you need more infos, logs and/or debug material please let me know and give clear instructions (especially for debugging). Thanks. Regards, - Sedat - -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.2.0-10463.1-iniza-small (sedat.dilek at gmail.com@fambox) (gcc version 4.9.2 (Ubuntu
Re: [PATCH] intel: Update i915_drm.h and correct misspelled caching
On Fri, Aug 16, 2013 at 9:31 PM, Ian Romanick i...@freedesktop.org wrote:
On 08/14/2013 01:19 AM, Sedat Dilek wrote:
AFAICS, there are more updates needed to be in sync with recent
kernel-drm.
I fell over the misspelling when digging into an issue in Linux-next.
The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
Here, I had a look especially at the defined macros (defines).
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
This should get Chris's ok before committing, but
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Thanks for the review.
Just FYI: For intel-ddx... the misspellings were fixed already.
- Sedat -
[1]
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=6bd897157b34e3b80dea68fa615d0fba08238486
---
include/drm/i915_drm.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..61a8407 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -195,8 +195,8 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_WAIT 0x2c
#define DRM_I915_GEM_CONTEXT_CREATE 0x2d
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
-#define DRM_I915_GEM_SET_CACHEING 0x2f
-#define DRM_I915_GEM_GET_CACHEING 0x30
+#define DRM_I915_GEM_SET_CACHING 0x2f
+#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -222,8 +222,8 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_PINDRM_IOWR(DRM_COMMAND_BASE
+ DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
#define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
#define DRM_IOCTL_I915_GEM_BUSY DRM_IOWR(DRM_COMMAND_BASE
+ DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
-#define DRM_IOCTL_I915_GEM_SET_CACHEING
DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHEING, struct
drm_i915_gem_cacheing)
-#define DRM_IOCTL_I915_GEM_GET_CACHEING
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHEING, struct
drm_i915_gem_cacheing)
+#define DRM_IOCTL_I915_GEM_SET_CACHING DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_SET_CACHING, struct drm_i915_gem_caching)
+#define DRM_IOCTL_I915_GEM_GET_CACHING DRM_IOWR(DRM_COMMAND_BASE
+ DRM_I915_GEM_GET_CACHING, struct drm_i915_gem_caching)
#define DRM_IOCTL_I915_GEM_THROTTLE DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_GEM_THROTTLE)
#define DRM_IOCTL_I915_GEM_ENTERVTDRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_ENTERVT)
#define DRM_IOCTL_I915_GEM_LEAVEVTDRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_LEAVEVT)
@@ -706,21 +706,22 @@ struct drm_i915_gem_busy {
__u32 busy;
};
-#define I915_CACHEING_NONE 0
-#define I915_CACHEING_CACHED 1
+#define I915_CACHING_NONE 0
+#define I915_CACHING_CACHED1
+#define I915_CACHING_DISPLAY 2
-struct drm_i915_gem_cacheing {
+struct drm_i915_gem_caching {
/**
-* Handle of the buffer to set/get the cacheing level of. */
+* Handle of the buffer to set/get the caching level of. */
__u32 handle;
/**
* Cacheing level to apply or return value
*
-* bits0-15 are for generic cacheing control (i.e. the above
defined
+* bits0-15 are for generic caching control (i.e. the above
defined
* values). bits16-31 are reserved for platform-specific
variations
* (e.g. l3$ caching on gen7). */
- __u32 cacheing;
+ __u32 caching;
};
#define I915_TILING_NONE 0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel: Update i915_drm.h and correct misspelled caching
On Fri, Aug 16, 2013 at 9:31 PM, Ian Romanick wrote:
> On 08/14/2013 01:19 AM, Sedat Dilek wrote:
>>
>> AFAICS, there are more updates needed to be in sync with recent
>> kernel-drm.
>>
>> I fell over the misspelling when digging into an issue in Linux-next.
>> The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
>> Here, I had a look especially at the defined macros (defines).
>>
>> Signed-off-by: Sedat Dilek
>
>
> This should get Chris's ok before committing, but
>
> Reviewed-by: Ian Romanick
Thanks for the review.
Just FYI: For intel-ddx... the misspellings were fixed already.
- Sedat -
[1]
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=6bd897157b34e3b80dea68fa615d0fba08238486
>
>> ---
>> include/drm/i915_drm.h | 21 +++--
>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index aa983f3..61a8407 100644
>> --- a/include/drm/i915_drm.h
>> +++ b/include/drm/i915_drm.h
>> @@ -195,8 +195,8 @@ typedef struct _drm_i915_sarea {
>> #define DRM_I915_GEM_WAIT 0x2c
>> #define DRM_I915_GEM_CONTEXT_CREATE 0x2d
>> #define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
>> -#define DRM_I915_GEM_SET_CACHEING 0x2f
>> -#define DRM_I915_GEM_GET_CACHEING 0x30
>> +#define DRM_I915_GEM_SET_CACHING 0x2f
>> +#define DRM_I915_GEM_GET_CACHING 0x30
>> #define DRM_I915_REG_READ 0x31
>>
>> #define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
>> DRM_I915_INIT, drm_i915_init_t)
>> @@ -222,8 +222,8 @@ typedef struct _drm_i915_sarea {
>> #define DRM_IOCTL_I915_GEM_PINDRM_IOWR(DRM_COMMAND_BASE
>> + DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
>> #define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
>> DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
>> #define DRM_IOCTL_I915_GEM_BUSY DRM_IOWR(DRM_COMMAND_BASE
>> + DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
>> -#define DRM_IOCTL_I915_GEM_SET_CACHEING
>> DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHEING, struct
>> drm_i915_gem_cacheing)
>> -#define DRM_IOCTL_I915_GEM_GET_CACHEING
>> DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHEING, struct
>> drm_i915_gem_cacheing)
>> +#define DRM_IOCTL_I915_GEM_SET_CACHING DRM_IOW(DRM_COMMAND_BASE +
>> DRM_I915_GEM_SET_CACHING, struct drm_i915_gem_caching)
>> +#define DRM_IOCTL_I915_GEM_GET_CACHING DRM_IOWR(DRM_COMMAND_BASE
>> + DRM_I915_GEM_GET_CACHING, struct drm_i915_gem_caching)
>> #define DRM_IOCTL_I915_GEM_THROTTLE DRM_IO ( DRM_COMMAND_BASE +
>> DRM_I915_GEM_THROTTLE)
>> #define DRM_IOCTL_I915_GEM_ENTERVTDRM_IO(DRM_COMMAND_BASE +
>> DRM_I915_GEM_ENTERVT)
>> #define DRM_IOCTL_I915_GEM_LEAVEVTDRM_IO(DRM_COMMAND_BASE +
>> DRM_I915_GEM_LEAVEVT)
>> @@ -706,21 +706,22 @@ struct drm_i915_gem_busy {
>> __u32 busy;
>> };
>>
>> -#define I915_CACHEING_NONE 0
>> -#define I915_CACHEING_CACHED 1
>> +#define I915_CACHING_NONE 0
>> +#define I915_CACHING_CACHED1
>> +#define I915_CACHING_DISPLAY 2
>>
>> -struct drm_i915_gem_cacheing {
>> +struct drm_i915_gem_caching {
>> /**
>> -* Handle of the buffer to set/get the cacheing level of. */
>> +* Handle of the buffer to set/get the caching level of. */
>> __u32 handle;
>>
>> /**
>> * Cacheing level to apply or return value
>> *
>> -* bits0-15 are for generic cacheing control (i.e. the above
>> defined
>> +* bits0-15 are for generic caching control (i.e. the above
>> defined
>> * values). bits16-31 are reserved for platform-specific
>> variations
>> * (e.g. l3$ caching on gen7). */
>> - __u32 cacheing;
>> + __u32 caching;
>> };
>>
>> #define I915_TILING_NONE 0
>>
>
[PATCH] intel: Update i915_drm.h and correct misspelled caching
AFAICS, there are more updates needed to be in sync with recent kernel-drm.
I fell over the misspelling when digging into an issue in Linux-next.
The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
Here, I had a look especially at the defined macros (defines).
Signed-off-by: Sedat Dilek
---
include/drm/i915_drm.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..61a8407 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -195,8 +195,8 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_WAIT 0x2c
#define DRM_I915_GEM_CONTEXT_CREATE0x2d
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
-#define DRM_I915_GEM_SET_CACHEING 0x2f
-#define DRM_I915_GEM_GET_CACHEING 0x30
+#define DRM_I915_GEM_SET_CACHING 0x2f
+#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -222,8 +222,8 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
#define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
#define DRM_IOCTL_I915_GEM_BUSYDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
-#define DRM_IOCTL_I915_GEM_SET_CACHEING
DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHEING, struct
drm_i915_gem_cacheing)
-#define DRM_IOCTL_I915_GEM_GET_CACHEING
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHEING, struct
drm_i915_gem_cacheing)
+#define DRM_IOCTL_I915_GEM_SET_CACHING DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_SET_CACHING, struct drm_i915_gem_caching)
+#define DRM_IOCTL_I915_GEM_GET_CACHING DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_GET_CACHING, struct drm_i915_gem_caching)
#define DRM_IOCTL_I915_GEM_THROTTLEDRM_IO ( DRM_COMMAND_BASE +
DRM_I915_GEM_THROTTLE)
#define DRM_IOCTL_I915_GEM_ENTERVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_ENTERVT)
#define DRM_IOCTL_I915_GEM_LEAVEVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_LEAVEVT)
@@ -706,21 +706,22 @@ struct drm_i915_gem_busy {
__u32 busy;
};
-#define I915_CACHEING_NONE 0
-#define I915_CACHEING_CACHED 1
+#define I915_CACHING_NONE 0
+#define I915_CACHING_CACHED1
+#define I915_CACHING_DISPLAY 2
-struct drm_i915_gem_cacheing {
+struct drm_i915_gem_caching {
/**
-* Handle of the buffer to set/get the cacheing level of. */
+* Handle of the buffer to set/get the caching level of. */
__u32 handle;
/**
* Cacheing level to apply or return value
*
-* bits0-15 are for generic cacheing control (i.e. the above defined
+* bits0-15 are for generic caching control (i.e. the above defined
* values). bits16-31 are reserved for platform-specific variations
* (e.g. l3$ caching on gen7). */
- __u32 cacheing;
+ __u32 caching;
};
#define I915_TILING_NONE 0
--
1.8.3.4
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: After a logout from my BROKEN Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. What hardware and display do you have? It's a Samsung ultrabook with SandyBridge CPU. [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 using LVDS. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Did that make a difference? It shouldn't if the error is occuring before X even starts... NO, was just confused not seeing GT2 (HD-3000 was new to me) in my Xorg.log :-). As said logging out of Unity-2D and entering LightDM greeter - screen is fine. Starting again a Unity-2D session - no screen corruption, too. - Sedat - Some more testing: [1] With my X stack: FIRST BAD: next-20130812 LAST GOOD: next-20130809 [2] With Ubuntu's X stack: next-20130813 is OK (Xorg.log attached) drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack no problems). I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers See also attached files! - Sedat - git bisect start # good: [d4e4ab86bcba5a72779c43dc1459f71fea3d89c8] Linux 3.11-rc5 git bisect good d4e4ab86bcba5a72779c43dc1459f71fea3d89c8 # bad: [5b79c8eb1b61d499ca70cc3e4e2ced7822209876] Merge branch 'drm-intel-nightly' into 3.11.0-rc5-iniza-small git bisect bad 5b79c8eb1b61d499ca70cc3e4e2ced7822209876 # good: [36f2d1f151215c48d902947d64b86dc5ab277e19] drm/i915: rip out legacy encoder-mode_set callback git bisect good 36f2d1f151215c48d902947d64b86dc5ab277e19 # good: [c35426d2bc25b242ee2a9a7a1d62634be1e86bb0] drm/i915: Split plane watermark parameters into a separate struct git bisect good c35426d2bc25b242ee2a9a7a1d62634be1e86bb0 # good: [32c913e4369ce7bd1d16a9b6983f7b8975c13f5a] Merge tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel into drm-next git bisect good 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a # good: [d46f1c3f1372e3a72fab97c60480aa4a1084387f] drm/i915: Allow the GPU to cache stolen memory git bisect good d46f1c3f1372e3a72fab97c60480aa4a1084387f # bad: [b8a1868b10bb4fe7fb7d283da5d56064b1a189f4] drm/i915: Allow the user to set bo into the DISPLAY cache domain git bisect bad b8a1868b10bb4fe7fb7d283da5d56064b1a189f4 # bad: [a698a20e8cf9a946b0a491cb58ff96c0b4332d08] i915: Fix SDVO potentially turning off randomly git bisect bad a698a20e8cf9a946b0a491cb58ff96c0b4332d08 # bad: [8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1] drm/i915: Only do a chipset flush after a clflush git bisect bad 8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1 # bad: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen git bisect bad 5456fe3882812aba251886e36fe55bfefb8e8829 # first bad commit: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: After a logout from my BROKEN Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. What hardware and display do you have? It's a Samsung ultrabook with SandyBridge CPU. [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 using LVDS. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Did that make a difference? It shouldn't if the error is occuring before X even starts... NO, was just confused not seeing GT2 (HD-3000 was new to me) in my Xorg.log :-). As said logging out of Unity-2D and entering LightDM greeter - screen is fine. Starting again a Unity-2D session - no screen corruption, too. - Sedat - Some more testing: [1] With my X stack: FIRST BAD: next-20130812 LAST GOOD: next-20130809 [2] With Ubuntu's X stack: next-20130813 is OK (Xorg.log attached) drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack no problems). I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers See also attached files! With the attached revert-patch my system is OK (with my customized X stack). - Sedat - 0001-Revert-drm-i915-Allocate-LLC-ringbuffers-from-stolen.patch Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote: I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers See also attached files! With the attached revert-patch my system is OK (with my customized X stack). No indication of a GPU hang? I'm puzzled as to how this ends up with the scanout being misread. cat /sys/kernel/debug/dri/0/i915_gem_stolen cat /sys/kernel/debug/dri/0/i915_gem_framebuffer would be interesting. With revert-patch applied: $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen Stolen: 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote: I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers See also attached files! With the attached revert-patch my system is OK (with my customized X stack). No indication of a GPU hang? I'm puzzled as to how this ends up with the scanout being misread. cat /sys/kernel/debug/dri/0/i915_gem_stolen cat /sys/kernel/debug/dri/0/i915_gem_framebuffer would be interesting. With revert-patch applied: $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen Stolen: 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) Attached both outputs with GOOD and BAD (BROKEN) kernel. - Sedat - fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880074492840: pXg 5120KiB 36 02 158126 158126 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 8800736d8e00: pXg 5120KiB 36 02 -737 -737 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) Stolen: 880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size Stolen: 880073995c80: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable) 880073995800: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable) 880073995500: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable) 880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p mappable) Total 4 objects, 4620288 bytes, 4620288 GTT size ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote: I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers See also attached files! With the attached revert-patch my system is OK (with my customized X stack). No indication of a GPU hang? I'm puzzled as to how this ends up with the scanout being misread. cat /sys/kernel/debug/dri/0/i915_gem_stolen cat /sys/kernel/debug/dri/0/i915_gem_framebuffer would be interesting. Attached both outputs with GOOD and BAD (BROKEN) kernel. ggtt offset is the same for both setups, the only difference between the two is the location of fbcon in stolen memory. Can you please attach the output of intel_reg_dumper for good/bad? It's a long shot... Speaking of long shots, try this (slightly different to the earlier patch): diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a21f935..37ad772 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev, BUG(); } + if (obj-stolen INTEL_INFO(dev)-gen = 6) + alignment = 256 * 1024; + /* Note that the w/a also requires 64 PTE of padding following the * bo. We currently fill all unused PTE with the shadow page and so * we should always have valid PTE following the scanout preventing -- Files attached. - Sedat - fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88010c54fcc0: pXg 5120KiB 36 02 -591 -591 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring) fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880118928b40: pXg 5120KiB 36 02 -12 -12 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring) Stolen: 880072c39c80: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable) 880072c39800: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable) 880072c39500: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable) 88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p mappable) Total 4 objects, 4620288 bytes, 4620288 GTT size Stolen: 880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Nothing scarred me on a couple of read throughs.
What happens if you try:
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 112c5e1..9828d9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32
size)
return NULL;
ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
-4096, DRM_MM_SEARCH_DEFAULT);
+1024*1024, DRM_MM_SEARCH_DEFAULT);
if (ret) {
kfree(stolen);
return NULL;
--
Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read Ubuntu 12.04 LTS with the known background.
So-to-say 3/4 blind.
- Sedat -
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Nothing scarred me on a couple of read throughs.
What happens if you try:
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 112c5e1..9828d9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev,
u32 size)
return NULL;
ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
-4096, DRM_MM_SEARCH_DEFAULT);
+1024*1024, DRM_MM_SEARCH_DEFAULT);
if (ret) {
kfree(stolen);
return NULL;
--
Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read Ubuntu 12.04 LTS with the known background.
So-to-say 3/4 blind.
That implies that the scanout is always reading from the base of stolen.
Can you grab intel_reg_dumper so that I can check what values the
transcoder is set to?
At the moment, I am guessing that the display never sees the updated
surface offset and so persists with the value programmed by the BIOS -
which will be 0 and set to the base of stolen memory in the GTT. A
drm.debug=6 dmesg would help here as well.
If you forced a mode change, I think that too would restore the output.
With which kernel? Vanilla next-20130813? With any of your patches?
- Sedat -
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
ch...@chris-wilson.co.uk wrote:
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
ch...@chris-wilson.co.uk wrote:
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Nothing scarred me on a couple of read throughs.
What happens if you try:
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 112c5e1..9828d9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device
*dev, u32 size)
return NULL;
ret = drm_mm_insert_node(dev_priv-mm.stolen, stolen, size,
-4096, DRM_MM_SEARCH_DEFAULT);
+1024*1024, DRM_MM_SEARCH_DEFAULT);
if (ret) {
kfree(stolen);
return NULL;
--
Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read Ubuntu 12.04 LTS with the known background.
So-to-say 3/4 blind.
That implies that the scanout is always reading from the base of stolen.
Can you grab intel_reg_dumper so that I can check what values the
transcoder is set to?
At the moment, I am guessing that the display never sees the updated
surface offset and so persists with the value programmed by the BIOS -
which will be 0 and set to the base of stolen memory in the GTT. A
drm.debug=6 dmesg would help here as well.
If you forced a mode change, I think that too would restore the output.
With which kernel? Vanilla next-20130813? With any of your patches?
Any but the working one ;-)
Damn Gmail, they switched again the UI, f***.
This is d-i-n with Revert drm/i915: Allocate LLC ringbuffers from
stolen --- working one (no screen corruptions).
- Sedat -
Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
The diff might be interesting as the 2nd login makes the issue go away.
intel_reg_dumper output attached.
- Sedat -
PGETBL_CTL: 0x
GEN6_INSTDONE_1: 0xfffe
GEN6_INSTDONE_2: 0x
CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
DISPLAY_PORT_PLL_BIOS_0: 0x
DISPLAY_PORT_PLL_BIOS_1: 0x
DISPLAY_PORT_PLL_BIOS_2: 0x
FDI_PLL_FREQ_CTL: 0x
PIPEACONF: 0xc000 (enabled, active, pf-pd, rotate 0,
8bpc)
HTOTAL_A: 0x05cd0555 (1366 active, 1486 total)
HBLANK_A: 0x05cd0555 (1366 start, 1486 end)
HSYNC_A: 0x05a50585 (1414 start, 1446 end)
VTOTAL_A: 0x031702ff (768 active, 792 total)
VBLANK_A: 0x031702ff (768 start, 792 end)
VSYNC_A: 0x03060301 (770 start, 775 end)
VSYNCSHIFT_A: 0x
PIPEASRC: 0x055502ff (1366, 768)
PIPEA_DATA_M1: 0x7e32468a (TU 64, val 0x32468a 3294858)
PIPEA_DATA_N1: 0x0040 (val 0x40 4194304)
PIPEA_DATA_M2: 0x (TU 1, val 0x0 0)
PIPEA_DATA_N2: 0x (val 0x0 0)
PIPEA_LINK_M1: 0x00021845 (val 0x21845 137285)
PIPEA_LINK_N1: 0x0008 (val 0x8 524288)
PIPEA_LINK_M2: 0x (val 0x0 0)
PIPEA_LINK_N2: 0x (val 0x0 0)
DSPACNTR: 0xd8004400 (enabled)
DSPABASE: 0x
DSPASTRIDE: 0x1600 (88)
DSPASURF: 0x0047a000
DSPATILEOFF: 0x (0, 0)
PIPEBCONF: 0x (disabled, inactive, pf-pd, rotate
0, 8bpc)
HTOTAL_B: 0x (1 active, 1 total)
HBLANK_B: 0x (1 start, 1 end)
HSYNC_B: 0x (1 start, 1 end)
VTOTAL_B: 0x (1 active, 1 total
[PATCH] intel: Update i915_drm.h and correct misspelled caching
AFAICS, there are more updates needed to be in sync with recent kernel-drm.
I fell over the misspelling when digging into an issue in Linux-next.
The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
Here, I had a look especially at the defined macros (defines).
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
include/drm/i915_drm.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..61a8407 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -195,8 +195,8 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_WAIT 0x2c
#define DRM_I915_GEM_CONTEXT_CREATE0x2d
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
-#define DRM_I915_GEM_SET_CACHEING 0x2f
-#define DRM_I915_GEM_GET_CACHEING 0x30
+#define DRM_I915_GEM_SET_CACHING 0x2f
+#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -222,8 +222,8 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
#define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
#define DRM_IOCTL_I915_GEM_BUSYDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
-#define DRM_IOCTL_I915_GEM_SET_CACHEING
DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHEING, struct
drm_i915_gem_cacheing)
-#define DRM_IOCTL_I915_GEM_GET_CACHEING
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHEING, struct
drm_i915_gem_cacheing)
+#define DRM_IOCTL_I915_GEM_SET_CACHING DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_SET_CACHING, struct drm_i915_gem_caching)
+#define DRM_IOCTL_I915_GEM_GET_CACHING DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_GET_CACHING, struct drm_i915_gem_caching)
#define DRM_IOCTL_I915_GEM_THROTTLEDRM_IO ( DRM_COMMAND_BASE +
DRM_I915_GEM_THROTTLE)
#define DRM_IOCTL_I915_GEM_ENTERVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_ENTERVT)
#define DRM_IOCTL_I915_GEM_LEAVEVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_LEAVEVT)
@@ -706,21 +706,22 @@ struct drm_i915_gem_busy {
__u32 busy;
};
-#define I915_CACHEING_NONE 0
-#define I915_CACHEING_CACHED 1
+#define I915_CACHING_NONE 0
+#define I915_CACHING_CACHED1
+#define I915_CACHING_DISPLAY 2
-struct drm_i915_gem_cacheing {
+struct drm_i915_gem_caching {
/**
-* Handle of the buffer to set/get the cacheing level of. */
+* Handle of the buffer to set/get the caching level of. */
__u32 handle;
/**
* Cacheing level to apply or return value
*
-* bits0-15 are for generic cacheing control (i.e. the above defined
+* bits0-15 are for generic caching control (i.e. the above defined
* values). bits16-31 are reserved for platform-specific variations
* (e.g. l3$ caching on gen7). */
- __u32 cacheing;
+ __u32 caching;
};
#define I915_TILING_NONE 0
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek
> wrote:
>> On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson
>> wrote:
>>> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
>>>> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson >>> chris-wilson.co.uk> wrote:
>>>> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>>>> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson >>> >> chris-wilson.co.uk> wrote:
>>>> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>>>> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson >>> >> >> chris-wilson.co.uk> wrote:
>>>> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>>>> >> >> >> Files attached.
>>>> >> >> >
>>>> >> >> > Can you also please attach a full dmesg so I can check for anything
>>>> >> >> > unusual?
>>>> >> >> >
>>>> >> >
>>>> >> > Nothing scarred me on a couple of read throughs.
>>>> >> >
>>>> >> > What happens if you try:
>>>> >> >
>>>> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> >> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> >> > index 112c5e1..9828d9b 100644
>>>> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device
>>>> >> > *dev, u32 size)
>>>> >> > return NULL;
>>>> >> >
>>>> >> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
>>>> >> > -4096, DRM_MM_SEARCH_DEFAULT);
>>>> >> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
>>>> >> > if (ret) {
>>>> >> > kfree(stolen);
>>>> >> > return NULL;
>>>> >> >
>>>> >> > --
>>>> >>
>>>> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>>>> >> from the top).
>>>> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>>>> >> So-to-say 3/4 "blind".
>>>> >
>>>> > That implies that the scanout is always reading from the base of stolen.
>>>> > Can you grab intel_reg_dumper so that I can check what values the
>>>> > transcoder is set to?
>>>> >
>>>> > At the moment, I am guessing that the display never sees the updated
>>>> > surface offset and so persists with the value programmed by the BIOS -
>>>> > which will be 0 and set to the base of stolen memory in the GTT. A
>>>> > drm.debug=6 dmesg would help here as well.
>>>> >
>>>> > If you forced a mode change, I think that too would restore the output.
>>>>
>>>> With which kernel? Vanilla next-20130813? With any of your patches?
>>>
>>> Any but the working one ;-)
>>
>> Damn Gmail, they switched again the UI, f***.
>>
>> This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
>> stolen" <--- "working one" (no screen corruptions).
>>
>> - Sedat -
>
> Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
> The diff might be interesting as the 2nd login makes the issue go away.
>
intel_reg_dumper output attached.
- Sedat -
-- next part --
PGETBL_CTL: 0x
GEN6_INSTDONE_1: 0xfffe
GEN6_INSTDONE_2: 0x
CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
DISPLAY_PORT_PLL_BIOS_0: 0x
DISPLAY_PORT_PLL_BIOS_1: 0x
DISPLAY_PORT_PLL_BIOS_2: 0x
FDI_PLL_FREQ_CTL: 0x
PIPEACONF: 0xc000 (enabled, active, pf-pd, rotate 0,
8bpc)
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson
> wrote:
>> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson >> chris-wilson.co.uk> wrote:
>>> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>>> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson >> >> chris-wilson.co.uk> wrote:
>>> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>>> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson >> >> >> chris-wilson.co.uk> wrote:
>>> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>>> >> >> >> Files attached.
>>> >> >> >
>>> >> >> > Can you also please attach a full dmesg so I can check for anything
>>> >> >> > unusual?
>>> >> >> >
>>> >> >
>>> >> > Nothing scarred me on a couple of read throughs.
>>> >> >
>>> >> > What happens if you try:
>>> >> >
>>> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> >> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> >> > index 112c5e1..9828d9b 100644
>>> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device
>>> >> > *dev, u32 size)
>>> >> > return NULL;
>>> >> >
>>> >> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
>>> >> > -4096, DRM_MM_SEARCH_DEFAULT);
>>> >> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
>>> >> > if (ret) {
>>> >> > kfree(stolen);
>>> >> > return NULL;
>>> >> >
>>> >> > --
>>> >>
>>> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>>> >> from the top).
>>> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>>> >> So-to-say 3/4 "blind".
>>> >
>>> > That implies that the scanout is always reading from the base of stolen.
>>> > Can you grab intel_reg_dumper so that I can check what values the
>>> > transcoder is set to?
>>> >
>>> > At the moment, I am guessing that the display never sees the updated
>>> > surface offset and so persists with the value programmed by the BIOS -
>>> > which will be 0 and set to the base of stolen memory in the GTT. A
>>> > drm.debug=6 dmesg would help here as well.
>>> >
>>> > If you forced a mode change, I think that too would restore the output.
>>>
>>> With which kernel? Vanilla next-20130813? With any of your patches?
>>
>> Any but the working one ;-)
>
> Damn Gmail, they switched again the UI, f***.
>
> This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
> stolen" <--- "working one" (no screen corruptions).
>
> - Sedat -
Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
The diff might be interesting as the 2nd login makes the issue go away.
- Sedat -
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.11.0-rc5-next20130813-1-iniza-small (sedat.dilek
at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP
Tue Aug 13 10:49:01 CEST 2013
[0.00] Command line: BOOT_IMAGE=/vmlinuz.next
root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro drm.debug=6
[0.00] KERNEL supported cpus:
[0.00] Intel GenuineIntel
[0.00] AMD AuthenticAMD
[0.00] Centaur CentaurHauls
[0.00] Disabled fast string operations
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson
wrote:
> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson > >> chris-wilson.co.uk> wrote:
>> >> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson > >> >> chris-wilson.co.uk> wrote:
>> >> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> >> >> Files attached.
>> >> >> >
>> >> >> > Can you also please attach a full dmesg so I can check for anything
>> >> >> > unusual?
>> >> >> >
>> >> >
>> >> > Nothing scarred me on a couple of read throughs.
>> >> >
>> >> > What happens if you try:
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> >> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> >> > index 112c5e1..9828d9b 100644
>> >> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> >> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> >> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device
>> >> > *dev, u32 size)
>> >> > return NULL;
>> >> >
>> >> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
>> >> > -4096, DRM_MM_SEARCH_DEFAULT);
>> >> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
>> >> > if (ret) {
>> >> > kfree(stolen);
>> >> > return NULL;
>> >> >
>> >> > --
>> >>
>> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>> >> from the top).
>> >> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>> >> So-to-say 3/4 "blind".
>> >
>> > That implies that the scanout is always reading from the base of stolen.
>> > Can you grab intel_reg_dumper so that I can check what values the
>> > transcoder is set to?
>> >
>> > At the moment, I am guessing that the display never sees the updated
>> > surface offset and so persists with the value programmed by the BIOS -
>> > which will be 0 and set to the base of stolen memory in the GTT. A
>> > drm.debug=6 dmesg would help here as well.
>> >
>> > If you forced a mode change, I think that too would restore the output.
>>
>> With which kernel? Vanilla next-20130813? With any of your patches?
>
> Any but the working one ;-)
Damn Gmail, they switched again the UI, f***.
This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
stolen" <--- "working one" (no screen corruptions).
- Sedat -
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.11.0-rc5-2-din-small (sedat.dilek at
gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP
Tue Aug 13 18:17:01 CEST 2013
[0.00] Command line: BOOT_IMAGE=/vmlinuz.next
root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro drm.debug=6
[0.00] KERNEL supported cpus:
[0.00] Intel GenuineIntel
[0.00] AMD AuthenticAMD
[0.00] Centaur CentaurHauls
[0.00] Disabled fast string operations
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable
[0.00] BIOS-e820: [mem 0xd9c9f000-0xdae7efff] reserved
[0.00] BIOS-e820: [mem 0xdae7f000-0xdaf9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data
[0.00] BIOS-e8
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson
wrote:
> On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson > >> chris-wilson.co.uk> wrote:
>> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> >> Files attached.
>> >> >
>> >> > Can you also please attach a full dmesg so I can check for anything
>> >> > unusual?
>> >> >
>> >
>> > Nothing scarred me on a couple of read throughs.
>> >
>> > What happens if you try:
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > index 112c5e1..9828d9b 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev,
>> > u32 size)
>> > return NULL;
>> >
>> > ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
>> > -4096, DRM_MM_SEARCH_DEFAULT);
>> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
>> > if (ret) {
>> > kfree(stolen);
>> > return NULL;
>> >
>> > --
>>
>> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>> from the top).
>> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>> So-to-say 3/4 "blind".
>
> That implies that the scanout is always reading from the base of stolen.
> Can you grab intel_reg_dumper so that I can check what values the
> transcoder is set to?
>
> At the moment, I am guessing that the display never sees the updated
> surface offset and so persists with the value programmed by the BIOS -
> which will be 0 and set to the base of stolen memory in the GTT. A
> drm.debug=6 dmesg would help here as well.
>
> If you forced a mode change, I think that too would restore the output.
With which kernel? Vanilla next-20130813? With any of your patches?
- Sedat -
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
wrote:
> On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> Files attached.
>> >
>> > Can you also please attach a full dmesg so I can check for anything
>> > unusual?
>> >
>
> Nothing scarred me on a couple of read throughs.
>
> What happens if you try:
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 112c5e1..9828d9b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32
> size)
> return NULL;
>
> ret = drm_mm_insert_node(_priv->mm.stolen, stolen, size,
> -4096, DRM_MM_SEARCH_DEFAULT);
> +1024*1024, DRM_MM_SEARCH_DEFAULT);
> if (ret) {
> kfree(stolen);
> return NULL;
>
> --
Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
So-to-say 3/4 "blind".
- Sedat -
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote: >> Files attached. > > Can you also please attach a full dmesg so I can check for anything > unusual? > -2: BAD with your test-patch -3: GOOD with your patch - Sedat .- -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-rc5-next20130813-2-iniza-small (sedat.dilek at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Tue Aug 13 19:38:16 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz.next root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable [0.00] BIOS-e820: [mem 0xd9c9f000-0xdae7efff] reserved [0.00] BIOS-e820: [mem 0xdae7f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffd8-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x11fe00 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0C000 mask FE000 write-back [0.00] 3 base 0DC00 mask FFC00 uncachable [0.00] 4 base 0DB00 mask FFF00 uncachable [0.00] 5 base 1 mask FE000 write-back [0.00] 6 base 11FE0 mask FFFE0 uncachable [0.00] 7 base 0FFC0 mask FFFC0 write-protect [0.00] 8 disabled [0.00] 9 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xdb000 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f00e0-0x000f00ef] mapped at [880f00e0] [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] reserving inaccessible SNB gfx pages [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x0204c000, 0x0204cfff] PGTABLE [0.00] BRK [0x0204d000, 0x0204dfff] PGTABLE [0.00] BRK [0x0204e000, 0x0204efff] PGTABLE [0.00] init_memory_mapping: [mem 0x11fc0-0x11fdf] [0.00] [mem 0x11fc0-0x11fdf] page 2M [0.00] BRK [0x0204f000, 0x0204] PGTABLE [0.00] init_memory_mapping: [mem 0x11c00-0x11fbf] [0.00] [mem 0x11c00-0x11fbf] page 2M [0.00] init_memory_mapping: [mem 0x1-0x
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek >> wrote: >> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson > > chris-wilson.co.uk> wrote: >> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: >> >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek >> >>> wrote: >> >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: >> >>> > >> >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit >> >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829 >> >>> > Author: Chris Wilson >> >>> > Date: Thu Aug 8 14:41:07 2013 +0100 >> >>> > >> >>> > drm/i915: Allocate LLC ringbuffers from stolen >> >>> > >> >>> > As stolen objects now behave identically (wrt to default LLC >> >>> > cacheing) >> >>> > as their normal system counterparts, we no longer have to >> >>> > differentiate >> >>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as >> >>> > well. >> >>> > >> >>> > Signed-off-by: Chris Wilson >> >>> > Reviewed-by: Ville Syrj?l? >> >>> > Signed-off-by: Daniel Vetter >> >>> > >> >>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 >> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers >> >>> > >> >>> > See also attached files! >> >>> > >> >>> >> >>> With the attached revert-patch my system is OK (with my customized X >> >>> stack). >> >> >> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the >> >> scanout being misread. >> >> >> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen >> >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer >> >> >> >> would be interesting. > >> Attached both outputs with GOOD and BAD (BROKEN) kernel. > > ggtt offset is the same for both setups, the only difference between the > two is the location of fbcon in stolen memory. > > Can you please attach the output of intel_reg_dumper for good/bad? It's > a long shot... > > Speaking of long shots, try this (slightly different to the earlier patch): > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index a21f935..37ad772 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev, > BUG(); > } > > + if (obj->stolen && INTEL_INFO(dev)->gen >= 6) > + alignment = 256 * 1024; > + > /* Note that the w/a also requires 64 PTE of padding following the > * bo. We currently fill all unused PTE with the shadow page and so > * we should always have valid PTE following the scanout preventing > > > -- Files attached. - Sedat - -- next part -- fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88010c54fcc0: pXg 5120KiB 36 02 -591 -591 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring) -- next part -- fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880118928b40: pXg 5120KiB 36 02 -12 -12 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring) -- next part -- Stolen: 880072c39c80: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable) 880072c39800: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable) 880072c39500: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable) 88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p mappable) Total 4 objects, 4620288 bytes, 4620288 GTT size -- next part -- Stolen: 880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson > wrote: >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek >>> wrote: >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: >>> > >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829 >>> > Author: Chris Wilson >>> > Date: Thu Aug 8 14:41:07 2013 +0100 >>> > >>> > drm/i915: Allocate LLC ringbuffers from stolen >>> > >>> > As stolen objects now behave identically (wrt to default LLC cacheing) >>> > as their normal system counterparts, we no longer have to >>> > differentiate >>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as >>> > well. >>> > >>> > Signed-off-by: Chris Wilson >>> > Reviewed-by: Ville Syrj?l? >>> > Signed-off-by: Daniel Vetter >>> > >>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers >>> > >>> > See also attached files! >>> > >>> >>> With the attached revert-patch my system is OK (with my customized X stack). >> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the >> scanout being misread. >> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer >> >> would be interesting. > > With revert-patch applied: > > $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen > Stolen: >88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) > (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) > (stolen: ) (p mappable) > Total 1 objects, 4227072 bytes, 4227072 GTT size > > $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer > fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj > 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) > (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) > (stolen: ) (p mappable) > user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj > 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty > (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, > size: 0050) (p mappable) (blitter ring) > Attached both outputs with GOOD and BAD (BROKEN) kernel. - Sedat - -- next part -- fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880074492840: pXg 5120KiB 36 02 158126 158126 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) -- next part -- fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 8800736d8e00: pXg 5120KiB 36 02 -737 -737 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) -- next part -- Stolen: 880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size -- next part -- Stolen: 880073995c80: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable) 880073995800: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable) 880073995500: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable) 880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p mappable) Total 4 objects, 4620288 bytes, 4620288 GTT size
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek >> wrote: >> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: >> > >> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit >> > commit 5456fe3882812aba251886e36fe55bfefb8e8829 >> > Author: Chris Wilson >> > Date: Thu Aug 8 14:41:07 2013 +0100 >> > >> > drm/i915: Allocate LLC ringbuffers from stolen >> > >> > As stolen objects now behave identically (wrt to default LLC cacheing) >> > as their normal system counterparts, we no longer have to differentiate >> > our usage for ringbuffers. So allocate them from stolen on SNB+ as >> > well. >> > >> > Signed-off-by: Chris Wilson >> > Reviewed-by: Ville Syrj?l? >> > Signed-off-by: Daniel Vetter >> > >> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 >> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers >> > >> > See also attached files! >> > >> >> With the attached revert-patch my system is OK (with my customized X stack). > > No indication of a GPU hang? I'm puzzled as to how this ends up with the > scanout being misread. > > cat /sys/kernel/debug/dri/0/i915_gem_stolen > cat /sys/kernel/debug/dri/0/i915_gem_framebuffer > > would be interesting. With revert-patch applied: $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen Stolen: 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) - Sedat -
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek >> wrote: >>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek >>> wrote: >>>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson >>> chris-wilson.co.uk> wrote: >>>>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: >>>>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson >>>>> chris-wilson.co.uk> wrote: >>>>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: >>>>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen >>>>>> >> for LightDM seems to be OK. >>>>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions. >>>>>> > >>>>>> > What hardware and display do you have? >>>>>> >>>>>> It's a Samsung ultrabook with SandyBridge CPU. >>>>>> >>>>>> [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD >>>>>> Graphics 3000 >>>>> >>>>> using LVDS. >>>>> >>>>>> - Sedat - >>>>>> >>>>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. >>>>> >>>>> Did that make a difference? It shouldn't if the error is occuring before >>>>> X even starts... >>>> >>>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my >>>> Xorg.log :-). >>>> >>>> As said logging out of Unity-2D and entering LightDM greeter - screen is >>>> fine. >>>> Starting again a Unity-2D session - no screen corruption, too. >>>> >>>> - Sedat - >>> >>> Some more testing: >>> >>> [1] With my X stack: >>> >>> FIRST BAD: next-20130812 >>> LAST GOOD: next-20130809 >>> >>> [2] With Ubuntu's X stack: >>> >>> next-20130813 is OK (Xorg.log attached) >>> >> >> drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack >> no problems). >> > > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: > > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit > commit 5456fe3882812aba251886e36fe55bfefb8e8829 > Author: Chris Wilson > Date: Thu Aug 8 14:41:07 2013 +0100 > > drm/i915: Allocate LLC ringbuffers from stolen > > As stolen objects now behave identically (wrt to default LLC cacheing) > as their normal system counterparts, we no longer have to differentiate > our usage for ringbuffers. So allocate them from stolen on SNB+ as well. > > Signed-off-by: Chris Wilson > Reviewed-by: Ville Syrj?l? > Signed-off-by: Daniel Vetter > > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers > > See also attached files! > With the attached revert-patch my system is OK (with my customized X stack). - Sedat - -- next part -- A non-text attachment was scrubbed... Name: 0001-Revert-drm-i915-Allocate-LLC-ringbuffers-from-stolen.patch Type: application/octet-stream Size: 1029 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130813/a76e4928/attachment.obj>
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek >> wrote: >>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson >> chris-wilson.co.uk> wrote: >>>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: >>>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson >>>> chris-wilson.co.uk> wrote: >>>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: >>>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen >>>>> >> for LightDM seems to be OK. >>>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions. >>>>> > >>>>> > What hardware and display do you have? >>>>> >>>>> It's a Samsung ultrabook with SandyBridge CPU. >>>>> >>>>> [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD >>>>> Graphics 3000 >>>> >>>> using LVDS. >>>> >>>>> - Sedat - >>>>> >>>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. >>>> >>>> Did that make a difference? It shouldn't if the error is occuring before >>>> X even starts... >>> >>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my >>> Xorg.log :-). >>> >>> As said logging out of Unity-2D and entering LightDM greeter - screen is >>> fine. >>> Starting again a Unity-2D session - no screen corruption, too. >>> >>> - Sedat - >> >> Some more testing: >> >> [1] With my X stack: >> >> FIRST BAD: next-20130812 >> LAST GOOD: next-20130809 >> >> [2] With Ubuntu's X stack: >> >> next-20130813 is OK (Xorg.log attached) >> > > drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack > no problems). > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrj?l? Signed-off-by: Daniel Vetter :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers See also attached files! - Sedat - -- next part -- git bisect start # good: [d4e4ab86bcba5a72779c43dc1459f71fea3d89c8] Linux 3.11-rc5 git bisect good d4e4ab86bcba5a72779c43dc1459f71fea3d89c8 # bad: [5b79c8eb1b61d499ca70cc3e4e2ced7822209876] Merge branch 'drm-intel-nightly' into 3.11.0-rc5-iniza-small git bisect bad 5b79c8eb1b61d499ca70cc3e4e2ced7822209876 # good: [36f2d1f151215c48d902947d64b86dc5ab277e19] drm/i915: rip out legacy encoder->mode_set callback git bisect good 36f2d1f151215c48d902947d64b86dc5ab277e19 # good: [c35426d2bc25b242ee2a9a7a1d62634be1e86bb0] drm/i915: Split plane watermark parameters into a separate struct git bisect good c35426d2bc25b242ee2a9a7a1d62634be1e86bb0 # good: [32c913e4369ce7bd1d16a9b6983f7b8975c13f5a] Merge tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel into drm-next git bisect good 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a # good: [d46f1c3f1372e3a72fab97c60480aa4a1084387f] drm/i915: Allow the GPU to cache stolen memory git bisect good d46f1c3f1372e3a72fab97c60480aa4a1084387f # bad: [b8a1868b10bb4fe7fb7d283da5d56064b1a189f4] drm/i915: Allow the user to set bo into the DISPLAY cache domain git bisect bad b8a1868b10bb4fe7fb7d283da5d56064b1a189f4 # bad: [a698a20e8cf9a946b0a491cb58ff96c0b4332d08] i915: Fix SDVO potentially turning off randomly git bisect bad a698a20e8cf9a946b0a491cb58ff96c0b4332d08 # bad: [8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1] drm/i915: Only do a chipset flush after a clflush git bisect bad 8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1 # bad: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen git bisect bad 5456fe3882812aba251886e36fe55bfefb8e8829 # first bad commit: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen -- next part -- commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers f
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek > wrote: >> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson >> wrote: >>> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: >>>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson >>> chris-wilson.co.uk> wrote: >>>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: >>>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen >>>> >> for LightDM seems to be OK. >>>> >> Then entering my Unity-2D desktop is OK - no screen corruptions. >>>> > >>>> > What hardware and display do you have? >>>> >>>> It's a Samsung ultrabook with SandyBridge CPU. >>>> >>>> [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD >>>> Graphics 3000 >>> >>> using LVDS. >>> >>>> - Sedat - >>>> >>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. >>> >>> Did that make a difference? It shouldn't if the error is occuring before >>> X even starts... >> >> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my >> Xorg.log :-). >> >> As said logging out of Unity-2D and entering LightDM greeter - screen is >> fine. >> Starting again a Unity-2D session - no screen corruption, too. >> >> - Sedat - > > Some more testing: > > [1] With my X stack: > > FIRST BAD: next-20130812 > LAST GOOD: next-20130809 > > [2] With Ubuntu's X stack: > > next-20130813 is OK (Xorg.log attached) > drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack no problems). - Sedat - > - Sedat -
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson > wrote: >> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: >>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson >> chris-wilson.co.uk> wrote: >>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: >>> >> After a logout from my "BROKEN" Unity-2D session - the login-screen >>> >> for LightDM seems to be OK. >>> >> Then entering my Unity-2D desktop is OK - no screen corruptions. >>> > >>> > What hardware and display do you have? >>> >>> It's a Samsung ultrabook with SandyBridge CPU. >>> >>> [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD >>> Graphics 3000 >> >> using LVDS. >> >>> - Sedat - >>> >>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. >> >> Did that make a difference? It shouldn't if the error is occuring before >> X even starts... > > NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my > Xorg.log :-). > > As said logging out of Unity-2D and entering LightDM greeter - screen is fine. > Starting again a Unity-2D session - no screen corruption, too. > > - Sedat - Some more testing: [1] With my X stack: FIRST BAD: next-20130812 LAST GOOD: next-20130809 [2] With Ubuntu's X stack: next-20130813 is OK (Xorg.log attached) - Sedat - -- next part -- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 37861 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130813/ca24d1ff/attachment-0001.obj>
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson >> wrote: >> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: >> >> After a logout from my "BROKEN" Unity-2D session - the login-screen >> >> for LightDM seems to be OK. >> >> Then entering my Unity-2D desktop is OK - no screen corruptions. >> > >> > What hardware and display do you have? >> >> It's a Samsung ultrabook with SandyBridge CPU. >> >> [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD >> Graphics 3000 > > using LVDS. > >> - Sedat - >> >> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. > > Did that make a difference? It shouldn't if the error is occuring before > X even starts... NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my Xorg.log :-). As said logging out of Unity-2D and entering LightDM greeter - screen is fine. Starting again a Unity-2D session - no screen corruption, too. - Sedat -
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: >> After a logout from my "BROKEN" Unity-2D session - the login-screen >> for LightDM seems to be OK. >> Then entering my Unity-2D desktop is OK - no screen corruptions. > > What hardware and display do you have? It's a Samsung ultrabook with SandyBridge CPU. [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 xrand output attached. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. -- next part -- Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 LVDS1 connected 1366x768+0+0 (0x45) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x41 Timestamp: 339571 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: BACKLIGHT: 7 (0x0007) range: (0,7) Backlight: 7 (0x0007) range: (0,7) scaling mode: Full aspect supported: None Full Center Full aspect 1366x768 (0x45) 70.7MHz -HSync -VSync *current +preferred h: width 1366 start 1414 end 1446 total 1486 skew0 clock 47.6KHz v: height 768 start 770 end 775 total 792 clock 60.1Hz 1360x768 (0x46) 84.8MHz -HSync +VSync h: width 1360 start 1432 end 1568 total 1776 skew0 clock 47.7KHz v: height 768 start 771 end 781 total 798 clock 59.8Hz 1360x768 (0x47) 72.0MHz +HSync -VSync h: width 1360 start 1408 end 1440 total 1520 skew0 clock 47.4KHz v: height 768 start 771 end 781 total 790 clock 60.0Hz 1024x768 (0x48) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x49) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x4a) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x4b) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 59.9Hz VGA1 disconnected (normal left inverted right x axis y axis) Identifier: 0x42 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: HDMI1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: Broadcast RGB: Automatic supported: AutomaticFull Limited 16:2 audio: auto supported: force-dvioff auto on DP1 disconnected (normal left inverted right x axis y axis) Identifier: 0x44 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: Broadcast RGB: Automatic supported: AutomaticFull Limited 16:2 audio: auto supported: force-dvioff auto on
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote: >> Hi, >> >> with today's next-20130813 I cannot see 1/10 of my desktop-screen's >> top, it's simply black. >> I can estimate the URL line in Firefox (or open a new tab blindly and >> get a known URL from my autocompleted history). > > Can you attach a photograph? > It's a black bar on the top of my desktop-screen - approx. 1/10. It looks like this is also in the VT on bootup before entering LightDM. >> My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. >> next-20130808 was OK - no screen corruptions. >> >> Any idea, hint? > > Can you please try: > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index af1b2f0..b0f181d 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev, > break; > case I915_TILING_X: > /* pin() will align the object as required by fence */ > - alignment = 0; > + alignment = 256 * 1024; > break; > case I915_TILING_Y: > /* Despite that we check this in framebuffer_init userspace > can > > -- NO, that did not help. After a logout from my "BROKEN" Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. - Sedat -
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:14 AM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek > wrote: >> On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell >> wrote: >>> Hi all, >>> >>> Changes since 20130812: >>> >>> The ext4 tree gained a conflict against Linus' tree. >>> >>> The infiniband tree gained a build failure for which I applied a merge >>> fix patch and another so I used the version from next-20130812. >>> >>> The tty tree gained conflicts against the devicetree and tile trees. >>> >>> The usb tree gained a conflict against the net-next tree. >>> >>> The usb-gadget tree gained a build failure for which I reverted a commit. >>> >>> The ptr-ret tree gained a conflict against the staging tree. >>> >>> The akpm tree gained a conflict against the staging tree. >>> >>> >>> >> >> Hi, >> >> with today's next-20130813 I cannot see 1/10 of my desktop-screen's >> top, it's simply black. >> I can estimate the URL line in Firefox (or open a new tab blindly and >> get a known URL from my autocompleted history). >> >> My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. >> next-20130808 was OK - no screen corruptions. >> >> Any idea, hint? >> >> - Sedat - > > [ From my dmesg ] > > [ 28.026524] [ cut here ] > [ 28.026557] WARNING: CPU: 3 PID: 639 at > drivers/gpu/drm/i915/i915_gem.c:3435 > i915_gem_object_set_cache_level+0x389/0x3a0 [i915]() > [ 28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm > snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc > snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq > btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper > videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth > videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp > mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169 > mii > [ 28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted > 3.11.0-rc5-next20130813-1-iniza-small #1 > [ 28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD. > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 > [ 28.026616] 0d6b 8800795535a8 816e259a > 0007 > [ 28.026622] 8800795535e8 810661dc > 81376e70 > [ 28.026627] 8800746ba200 8800746ba2b8 88007a2c7000 > 0041 > [ 28.026632] Call Trace: > [ 28.026641] [] dump_stack+0x46/0x58 > [ 28.026647] [] warn_slowpath_common+0x8c/0xc0 > [ 28.026653] [] ? sg_kfree+0x30/0x30 > [ 28.026658] [] warn_slowpath_null+0x1a/0x20 > [ 28.026680] [] > i915_gem_object_set_cache_level+0x389/0x3a0 [i915] > [ 28.026684] [] ? sg_alloc_table+0x1f/0x50 > [ 28.026703] [] > i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915] > [ 28.026727] [] > intel_pin_and_fence_fb_obj+0xc0/0x140 [i915] > [ 28.026732] [] ? mutex_lock+0x1e/0x40 > [ 28.026761] [] intelfb_create+0x107/0x510 [i915] > [ 28.026778] [] ? drm_mode_create+0x47/0x70 [drm] > [ 28.026786] [] > drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper] > [ 28.026813] [] ? i915_write32+0xc3/0x190 [i915] > [ 28.026838] [] intel_fbdev_initial_config+0x21/0x30 > [i915] > [ 28.026859] [] i915_driver_load+0xe9d/0xed0 [i915] > [ 28.026876] [] drm_get_pci_dev+0x181/0x2a0 [drm] > [ 28.026881] [] ? do_raw_spin_unlock+0x5d/0xb0 > [ 28.026900] [] i915_pci_probe+0x36/0x70 [i915] > [ 28.026905] [] local_pci_probe+0x4b/0x80 > [ 28.026910] [] pci_device_probe+0x101/0x120 > [ 28.026915] [] driver_probe_device+0x7b/0x240 > [ 28.026920] [] __driver_attach+0xab/0xb0 > [ 28.026924] [] ? driver_probe_device+0x240/0x240 > [ 28.026928] [] bus_for_each_dev+0x5e/0x90 > [ 28.026932] [] driver_attach+0x1e/0x20 > [ 28.026936] [] bus_add_driver+0x104/0x2a0 > [ 28.026941] [] driver_register+0x64/0xf0 > [ 28.026946] [] __pci_register_driver+0x64/0x70 > [ 28.026951] [] ? 0xa0474fff > [ 28.026963] [] drm_pci_init+0x11a/0x130 [drm] > [ 28.026968] [] ? 0xa0474fff > [ 28.026987] [] i915_init+0x66/0x68 [i915] > [ 28.026992] [] do_one_initcall+0x4e/0x180 > [ 28.026997] [] ? set_memory_nx+0x43/0x50 > [ 28.027003] [] load_module+0x209c/0x25b0 > [ 28.027007] [] ? show_initstate+0x50/0x50 > [ 28.027013] [] SyS_init_module+0xac/0xd0 > [ 28.027018] [] tracesys+0xe1/0xe6 > [ 28.027022] ---[ end trace be830cf8c302dde8 ]--- > > > - Sedat - Looks like there is patch to fix this WARNING, do not think it fixes my screen corruption. - Sedat - http://lists.freedesktop.org/archives/intel-gfx/2013-August/031701.html
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell > wrote: >> Hi all, >> >> Changes since 20130812: >> >> The ext4 tree gained a conflict against Linus' tree. >> >> The infiniband tree gained a build failure for which I applied a merge >> fix patch and another so I used the version from next-20130812. >> >> The tty tree gained conflicts against the devicetree and tile trees. >> >> The usb tree gained a conflict against the net-next tree. >> >> The usb-gadget tree gained a build failure for which I reverted a commit. >> >> The ptr-ret tree gained a conflict against the staging tree. >> >> The akpm tree gained a conflict against the staging tree. >> >> >> > > Hi, > > with today's next-20130813 I cannot see 1/10 of my desktop-screen's > top, it's simply black. > I can estimate the URL line in Firefox (or open a new tab blindly and > get a known URL from my autocompleted history). > > My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. > next-20130808 was OK - no screen corruptions. > > Any idea, hint? > > - Sedat - [ From my dmesg ] [ 28.026524] [ cut here ] [ 28.026557] WARNING: CPU: 3 PID: 639 at drivers/gpu/drm/i915/i915_gem.c:3435 i915_gem_object_set_cache_level+0x389/0x3a0 [i915]() [ 28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169 mii [ 28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted 3.11.0-rc5-next20130813-1-iniza-small #1 [ 28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 28.026616] 0d6b 8800795535a8 816e259a 0007 [ 28.026622] 8800795535e8 810661dc 81376e70 [ 28.026627] 8800746ba200 8800746ba2b8 88007a2c7000 0041 [ 28.026632] Call Trace: [ 28.026641] [] dump_stack+0x46/0x58 [ 28.026647] [] warn_slowpath_common+0x8c/0xc0 [ 28.026653] [] ? sg_kfree+0x30/0x30 [ 28.026658] [] warn_slowpath_null+0x1a/0x20 [ 28.026680] [] i915_gem_object_set_cache_level+0x389/0x3a0 [i915] [ 28.026684] [] ? sg_alloc_table+0x1f/0x50 [ 28.026703] [] i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915] [ 28.026727] [] intel_pin_and_fence_fb_obj+0xc0/0x140 [i915] [ 28.026732] [] ? mutex_lock+0x1e/0x40 [ 28.026761] [] intelfb_create+0x107/0x510 [i915] [ 28.026778] [] ? drm_mode_create+0x47/0x70 [drm] [ 28.026786] [] drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper] [ 28.026813] [] ? i915_write32+0xc3/0x190 [i915] [ 28.026838] [] intel_fbdev_initial_config+0x21/0x30 [i915] [ 28.026859] [] i915_driver_load+0xe9d/0xed0 [i915] [ 28.026876] [] drm_get_pci_dev+0x181/0x2a0 [drm] [ 28.026881] [] ? do_raw_spin_unlock+0x5d/0xb0 [ 28.026900] [] i915_pci_probe+0x36/0x70 [i915] [ 28.026905] [] local_pci_probe+0x4b/0x80 [ 28.026910] [] pci_device_probe+0x101/0x120 [ 28.026915] [] driver_probe_device+0x7b/0x240 [ 28.026920] [] __driver_attach+0xab/0xb0 [ 28.026924] [] ? driver_probe_device+0x240/0x240 [ 28.026928] [] bus_for_each_dev+0x5e/0x90 [ 28.026932] [] driver_attach+0x1e/0x20 [ 28.026936] [] bus_add_driver+0x104/0x2a0 [ 28.026941] [] driver_register+0x64/0xf0 [ 28.026946] [] __pci_register_driver+0x64/0x70 [ 28.026951] [] ? 0xa0474fff [ 28.026963] [] drm_pci_init+0x11a/0x130 [drm] [ 28.026968] [] ? 0xa0474fff [ 28.026987] [] i915_init+0x66/0x68 [i915] [ 28.026992] [] do_one_initcall+0x4e/0x180 [ 28.026997] [] ? set_memory_nx+0x43/0x50 [ 28.027003] [] load_module+0x209c/0x25b0 [ 28.027007] [] ? show_initstate+0x50/0x50 [ 28.027013] [] SyS_init_module+0xac/0xd0 [ 28.027018] [] tracesys+0xe1/0xe6 [ 28.027022] ---[ end trace be830cf8c302dde8 ]--- - Sedat - -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-rc5-next20130813-1-iniza-small (sedat.dilek at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Tue Aug 13 10:49:01 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz.next root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro [0.
linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130812: > > The ext4 tree gained a conflict against Linus' tree. > > The infiniband tree gained a build failure for which I applied a merge > fix patch and another so I used the version from next-20130812. > > The tty tree gained conflicts against the devicetree and tile trees. > > The usb tree gained a conflict against the net-next tree. > > The usb-gadget tree gained a build failure for which I reverted a commit. > > The ptr-ret tree gained a conflict against the staging tree. > > The akpm tree gained a conflict against the staging tree. > > > Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? - Sedat -
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130812: The ext4 tree gained a conflict against Linus' tree. The infiniband tree gained a build failure for which I applied a merge fix patch and another so I used the version from next-20130812. The tty tree gained conflicts against the devicetree and tile trees. The usb tree gained a conflict against the net-next tree. The usb-gadget tree gained a build failure for which I reverted a commit. The ptr-ret tree gained a conflict against the staging tree. The akpm tree gained a conflict against the staging tree. Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:14 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130812: The ext4 tree gained a conflict against Linus' tree. The infiniband tree gained a build failure for which I applied a merge fix patch and another so I used the version from next-20130812. The tty tree gained conflicts against the devicetree and tile trees. The usb tree gained a conflict against the net-next tree. The usb-gadget tree gained a build failure for which I reverted a commit. The ptr-ret tree gained a conflict against the staging tree. The akpm tree gained a conflict against the staging tree. Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? - Sedat - [ From my dmesg ] [ 28.026524] [ cut here ] [ 28.026557] WARNING: CPU: 3 PID: 639 at drivers/gpu/drm/i915/i915_gem.c:3435 i915_gem_object_set_cache_level+0x389/0x3a0 [i915]() [ 28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169 mii [ 28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted 3.11.0-rc5-next20130813-1-iniza-small #1 [ 28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 28.026616] 0d6b 8800795535a8 816e259a 0007 [ 28.026622] 8800795535e8 810661dc 81376e70 [ 28.026627] 8800746ba200 8800746ba2b8 88007a2c7000 0041 [ 28.026632] Call Trace: [ 28.026641] [816e259a] dump_stack+0x46/0x58 [ 28.026647] [810661dc] warn_slowpath_common+0x8c/0xc0 [ 28.026653] [81376e70] ? sg_kfree+0x30/0x30 [ 28.026658] [8106622a] warn_slowpath_null+0x1a/0x20 [ 28.026680] [a03e1fe9] i915_gem_object_set_cache_level+0x389/0x3a0 [i915] [ 28.026684] [8137723f] ? sg_alloc_table+0x1f/0x50 [ 28.026703] [a03e2162] i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915] [ 28.026727] [a03f9b10] intel_pin_and_fence_fb_obj+0xc0/0x140 [i915] [ 28.026732] [816e82ee] ? mutex_lock+0x1e/0x40 [ 28.026761] [a0424277] intelfb_create+0x107/0x510 [i915] [ 28.026778] [a020f807] ? drm_mode_create+0x47/0x70 [drm] [ 28.026786] [a01a404e] drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper] [ 28.026813] [a0431323] ? i915_write32+0xc3/0x190 [i915] [ 28.026838] [a0424751] intel_fbdev_initial_config+0x21/0x30 [i915] [ 28.026859] [a03cb38d] i915_driver_load+0xe9d/0xed0 [i915] [ 28.026876] [a020aad1] drm_get_pci_dev+0x181/0x2a0 [drm] [ 28.026881] [8137b12d] ? do_raw_spin_unlock+0x5d/0xb0 [ 28.026900] [a03c75d6] i915_pci_probe+0x36/0x70 [i915] [ 28.026905] [81399ceb] local_pci_probe+0x4b/0x80 [ 28.026910] [8139b5c1] pci_device_probe+0x101/0x120 [ 28.026915] [81478a1b] driver_probe_device+0x7b/0x240 [ 28.026920] [81478c8b] __driver_attach+0xab/0xb0 [ 28.026924] [81478be0] ? driver_probe_device+0x240/0x240 [ 28.026928] [81476b6e] bus_for_each_dev+0x5e/0x90 [ 28.026932] [8147851e] driver_attach+0x1e/0x20 [ 28.026936] [81477fc4] bus_add_driver+0x104/0x2a0 [ 28.026941] [814793f4] driver_register+0x64/0xf0 [ 28.026946] [8139a544] __pci_register_driver+0x64/0x70 [ 28.026951] [a0475000] ? 0xa0474fff [ 28.026963] [a020ad0a] drm_pci_init+0x11a/0x130 [drm] [ 28.026968] [a0475000] ? 0xa0474fff [ 28.026987] [a0475066] i915_init+0x66/0x68 [i915] [ 28.026992] [8100207e] do_one_initcall+0x4e/0x180 [ 28.026997] [81058413] ? set_memory_nx+0x43/0x50 [ 28.027003] [810d147c] load_module+0x209c/0x25b0 [ 28.027007] [810ce0a0] ? show_initstate+0x50/0x50 [ 28.027013] [810d1a3c] SyS_init_module+0xac/0xd0 [ 28.027018] [816f41ef] tracesys+0xe1/0xe6
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote: Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). Can you attach a photograph? It's a black bar on the top of my desktop-screen - approx. 1/10. It looks like this is also in the VT on bootup before entering LightDM. My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? Can you please try: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index af1b2f0..b0f181d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev, break; case I915_TILING_X: /* pin() will align the object as required by fence */ - alignment = 0; + alignment = 256 * 1024; break; case I915_TILING_Y: /* Despite that we check this in framebuffer_init userspace can -- NO, that did not help. After a logout from my BROKEN Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: After a logout from my BROKEN Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. What hardware and display do you have? It's a Samsung ultrabook with SandyBridge CPU. [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 xrand output attached. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 LVDS1 connected 1366x768+0+0 (0x45) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x41 Timestamp: 339571 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: BACKLIGHT: 7 (0x0007) range: (0,7) Backlight: 7 (0x0007) range: (0,7) scaling mode: Full aspect supported: None Full Center Full aspect 1366x768 (0x45) 70.7MHz -HSync -VSync *current +preferred h: width 1366 start 1414 end 1446 total 1486 skew0 clock 47.6KHz v: height 768 start 770 end 775 total 792 clock 60.1Hz 1360x768 (0x46) 84.8MHz -HSync +VSync h: width 1360 start 1432 end 1568 total 1776 skew0 clock 47.7KHz v: height 768 start 771 end 781 total 798 clock 59.8Hz 1360x768 (0x47) 72.0MHz +HSync -VSync h: width 1360 start 1408 end 1440 total 1520 skew0 clock 47.4KHz v: height 768 start 771 end 781 total 790 clock 60.0Hz 1024x768 (0x48) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x49) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x4a) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x4b) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 59.9Hz VGA1 disconnected (normal left inverted right x axis y axis) Identifier: 0x42 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: HDMI1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: Broadcast RGB: Automatic supported: AutomaticFull Limited 16:2 audio: auto supported: force-dvioff auto on DP1 disconnected (normal left inverted right x axis y axis) Identifier: 0x44 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: Broadcast RGB: Automatic supported: AutomaticFull Limited 16:2 audio: auto supported: force-dvioff auto on ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: After a logout from my BROKEN Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. What hardware and display do you have? It's a Samsung ultrabook with SandyBridge CPU. [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 using LVDS. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Did that make a difference? It shouldn't if the error is occuring before X even starts... NO, was just confused not seeing GT2 (HD-3000 was new to me) in my Xorg.log :-). As said logging out of Unity-2D and entering LightDM greeter - screen is fine. Starting again a Unity-2D session - no screen corruption, too. - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: After a logout from my BROKEN Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. What hardware and display do you have? It's a Samsung ultrabook with SandyBridge CPU. [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 using LVDS. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Did that make a difference? It shouldn't if the error is occuring before X even starts... NO, was just confused not seeing GT2 (HD-3000 was new to me) in my Xorg.log :-). As said logging out of Unity-2D and entering LightDM greeter - screen is fine. Starting again a Unity-2D session - no screen corruption, too. - Sedat - Some more testing: [1] With my X stack: FIRST BAD: next-20130812 LAST GOOD: next-20130809 [2] With Ubuntu's X stack: next-20130813 is OK (Xorg.log attached) - Sedat - Xorg.0.log Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: After a logout from my BROKEN Unity-2D session - the login-screen for LightDM seems to be OK. Then entering my Unity-2D desktop is OK - no screen corruptions. What hardware and display do you have? It's a Samsung ultrabook with SandyBridge CPU. [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 using LVDS. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Did that make a difference? It shouldn't if the error is occuring before X even starts... NO, was just confused not seeing GT2 (HD-3000 was new to me) in my Xorg.log :-). As said logging out of Unity-2D and entering LightDM greeter - screen is fine. Starting again a Unity-2D session - no screen corruption, too. - Sedat - Some more testing: [1] With my X stack: FIRST BAD: next-20130812 LAST GOOD: next-20130809 [2] With Ubuntu's X stack: next-20130813 is OK (Xorg.log attached) drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack no problems). - Sedat - - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: fix mmap vma size calculations
On Wed, Jul 31, 2013 at 6:46 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Tue, Jul 30, 2013 at 9:52 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Jul 30, 2013 at 9:41 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote: The VMA manager is page-size based so drm_vma_node_size() returns the size in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small buffers. This bug was introduced in commit: 0de23977cfeb5b357ec884ba15417ae118ff9e9b drm/gem: convert to new unified vma manager Fixes i915 gtt mmap failure reported by Sedat Dilek in: Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: David Herrmann dh.herrm...@gmail.com Reported-by: Sedat Dilek sedat.di...@gmail.com Tested-by: Sedat Dilek sedat.di...@gmail.com I remember that I even checked whether v4 was consistent with pages vs. bytes ;-) So Hi David, Daniel, and Dave, Just reading quickly drm: add unified vma offset manager... is that below in the docs? The VMA manager is page-size based so drm_vma_node_size() returns the size in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small buffers. If not, do you mind adding it? To quote this two: [ include/drm/drm_vma_manager.h ] /** * drm_vma_node_size() - Return size (page-based) * @node: Node to inspect * * Return the size as number of pages for the given node. This is the same size * that was passed to drm_vma_offset_add(). If no offset is allocated for the * node, this is 0. * * RETURNS: * Size of @node as number of pages. 0 if the node does not have an offset * allocated. */ [ drivers/gpu/drm/drm_gem.c ] It's actually drm_gem_mmap_obj which we have to look at and it says: * @obj_size: the object size to be mapped, in bytes So both are already documented. Good. I had only a quick view, you are the expert. Regards David /** * drm_gem_mmap - memory map routine for GEM objects * @filp: DRM file pointer * @vma: VMA for the area to be mapped * * If a driver supports GEM object mapping, mmap calls on the DRM file * descriptor will end up here. * * Look up the GEM object based on the offset passed in (vma-vm_pgoff will * contain the fake offset we created when the GTT map ioctl was called on * the object) and map it with a call to drm_gem_mmap_obj(). */ - Sedat - Thanks in advance! - Sedat - Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch on this little fixup. -Daniel --- drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 3613b50..1f76572 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma) } obj = container_of(node, struct drm_gem_object, vma_node); - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma); + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) PAGE_SHIFT, vma); mutex_unlock(dev-struct_mutex); -- 1.8.3.4 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/gem: fix mmap vma size calculations
On Wed, Jul 31, 2013 at 6:46 PM, David Herrmann wrote: > Hi > > On Tue, Jul 30, 2013 at 9:52 AM, Sedat Dilek wrote: >> On Tue, Jul 30, 2013 at 9:41 AM, Sedat Dilek >> wrote: >>> On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter wrote: >>>> On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote: >>>>> The VMA manager is page-size based so drm_vma_node_size() returns the size >>>>> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply >>>>> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small >>>>> buffers. >>>>> >>>>> This bug was introduced in commit: >>>>> 0de23977cfeb5b357ec884ba15417ae118ff9e9b >>>>> "drm/gem: convert to new unified vma manager" >>>>> >>>>> Fixes i915 gtt mmap failure reported by Sedat Dilek in: >>>>> Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] >>>>> >>>>> Cc: Daniel Vetter >>>>> Cc: Chris Wilson >>>>> Signed-off-by: David Herrmann >>>>> Reported-by: Sedat Dilek >>>>> Tested-by: Sedat Dilek >>>> >>>> I remember that I even checked whether v4 was consistent with pages vs. >>>> bytes ;-) So >>>> >>> >>> Hi David, Daniel, and Dave, >>> >>> Just reading quickly "drm: add unified vma offset manager"... is that >>> below in the docs? >>> >>> "The VMA manager is page-size based so drm_vma_node_size() returns the size >>> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply >>> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small >>> buffers." >>> >>> If not, do you mind adding it? >>> >> >> To quote this two: >> >> [ include/drm/drm_vma_manager.h ] >> >> /** >> * drm_vma_node_size() - Return size (page-based) >> * @node: Node to inspect >> * >> * Return the size as number of pages for the given node. This is the same >> size >> * that was passed to drm_vma_offset_add(). If no offset is allocated for the >> * node, this is 0. >> * >> * RETURNS: >> * Size of @node as number of pages. 0 if the node does not have an offset >> * allocated. >> */ >> >> [ drivers/gpu/drm/drm_gem.c ] > > It's actually "drm_gem_mmap_obj" which we have to look at and it says: > * @obj_size: the object size to be mapped, in bytes > > So both are already documented. > Good. I had only a quick view, you are the expert. > Regards > David > >> /** >> * drm_gem_mmap - memory map routine for GEM objects >> * @filp: DRM file pointer >> * @vma: VMA for the area to be mapped >> * >> * If a driver supports GEM object mapping, mmap calls on the DRM file >> * descriptor will end up here. >> * >> * Look up the GEM object based on the offset passed in (vma->vm_pgoff will >> * contain the fake offset we created when the GTT map ioctl was called on >> * the object) and map it with a call to drm_gem_mmap_obj(). >> */ >> >> - Sedat - >> >>> Thanks in advance! >>> >>> - Sedat - >>> >>>> Reviewed-by: Daniel Vetter >>>> >>>> on this little fixup. >>>> -Daniel >>>> >>>>> --- >>>>> drivers/gpu/drm/drm_gem.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c >>>>> index 3613b50..1f76572 100644 >>>>> --- a/drivers/gpu/drm/drm_gem.c >>>>> +++ b/drivers/gpu/drm/drm_gem.c >>>>> @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct >>>>> vm_area_struct *vma) >>>>> } >>>>> >>>>> obj = container_of(node, struct drm_gem_object, vma_node); >>>>> - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma); >>>>> + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT, >>>>> vma); >>>>> >>>>> mutex_unlock(>struct_mutex); >>>>> >>>>> -- >>>>> 1.8.3.4 >>>>> >>>> >>>> -- >>>> Daniel Vetter >>>> Software Engineer, Intel Corporation >>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2] drm/gem: fix mmap vma size calculations
On Tue, Jul 30, 2013 at 9:41 AM, Sedat Dilek wrote: > On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter wrote: >> On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote: >>> The VMA manager is page-size based so drm_vma_node_size() returns the size >>> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply >>> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small >>> buffers. >>> >>> This bug was introduced in commit: >>> 0de23977cfeb5b357ec884ba15417ae118ff9e9b >>> "drm/gem: convert to new unified vma manager" >>> >>> Fixes i915 gtt mmap failure reported by Sedat Dilek in: >>> Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] >>> >>> Cc: Daniel Vetter >>> Cc: Chris Wilson >>> Signed-off-by: David Herrmann >>> Reported-by: Sedat Dilek >>> Tested-by: Sedat Dilek >> >> I remember that I even checked whether v4 was consistent with pages vs. >> bytes ;-) So >> > > Hi David, Daniel, and Dave, > > Just reading quickly "drm: add unified vma offset manager"... is that > below in the docs? > > "The VMA manager is page-size based so drm_vma_node_size() returns the size > in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply > PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small > buffers." > > If not, do you mind adding it? > To quote this two: [ include/drm/drm_vma_manager.h ] /** * drm_vma_node_size() - Return size (page-based) * @node: Node to inspect * * Return the size as number of pages for the given node. This is the same size * that was passed to drm_vma_offset_add(). If no offset is allocated for the * node, this is 0. * * RETURNS: * Size of @node as number of pages. 0 if the node does not have an offset * allocated. */ [ drivers/gpu/drm/drm_gem.c ] /** * drm_gem_mmap - memory map routine for GEM objects * @filp: DRM file pointer * @vma: VMA for the area to be mapped * * If a driver supports GEM object mapping, mmap calls on the DRM file * descriptor will end up here. * * Look up the GEM object based on the offset passed in (vma->vm_pgoff will * contain the fake offset we created when the GTT map ioctl was called on * the object) and map it with a call to drm_gem_mmap_obj(). */ - Sedat - > Thanks in advance! > > - Sedat - > >> Reviewed-by: Daniel Vetter >> >> on this little fixup. >> -Daniel >> >>> --- >>> drivers/gpu/drm/drm_gem.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c >>> index 3613b50..1f76572 100644 >>> --- a/drivers/gpu/drm/drm_gem.c >>> +++ b/drivers/gpu/drm/drm_gem.c >>> @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct >>> vm_area_struct *vma) >>> } >>> >>> obj = container_of(node, struct drm_gem_object, vma_node); >>> - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma); >>> + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT, >>> vma); >>> >>> mutex_unlock(>struct_mutex); >>> >>> -- >>> 1.8.3.4 >>> >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2] drm/gem: fix mmap vma size calculations
On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter wrote: > On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote: >> The VMA manager is page-size based so drm_vma_node_size() returns the size >> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply >> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small >> buffers. >> >> This bug was introduced in commit: >> 0de23977cfeb5b357ec884ba15417ae118ff9e9b >> "drm/gem: convert to new unified vma manager" >> >> Fixes i915 gtt mmap failure reported by Sedat Dilek in: >> Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] >> >> Cc: Daniel Vetter >> Cc: Chris Wilson >> Signed-off-by: David Herrmann >> Reported-by: Sedat Dilek >> Tested-by: Sedat Dilek > > I remember that I even checked whether v4 was consistent with pages vs. > bytes ;-) So > Hi David, Daniel, and Dave, Just reading quickly "drm: add unified vma offset manager"... is that below in the docs? "The VMA manager is page-size based so drm_vma_node_size() returns the size in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small buffers." If not, do you mind adding it? Thanks in advance! - Sedat - > Reviewed-by: Daniel Vetter > > on this little fixup. > -Daniel > >> --- >> drivers/gpu/drm/drm_gem.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c >> index 3613b50..1f76572 100644 >> --- a/drivers/gpu/drm/drm_gem.c >> +++ b/drivers/gpu/drm/drm_gem.c >> @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct >> vm_area_struct *vma) >> } >> >> obj = container_of(node, struct drm_gem_object, vma_node); >> - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma); >> + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT, >> vma); >> >> mutex_unlock(>struct_mutex); >> >> -- >> 1.8.3.4 >> > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH v2] drm/gem: fix mmap vma size calculations
On Tue, Jul 30, 2013 at 9:41 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote: The VMA manager is page-size based so drm_vma_node_size() returns the size in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small buffers. This bug was introduced in commit: 0de23977cfeb5b357ec884ba15417ae118ff9e9b drm/gem: convert to new unified vma manager Fixes i915 gtt mmap failure reported by Sedat Dilek in: Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: David Herrmann dh.herrm...@gmail.com Reported-by: Sedat Dilek sedat.di...@gmail.com Tested-by: Sedat Dilek sedat.di...@gmail.com I remember that I even checked whether v4 was consistent with pages vs. bytes ;-) So Hi David, Daniel, and Dave, Just reading quickly drm: add unified vma offset manager... is that below in the docs? The VMA manager is page-size based so drm_vma_node_size() returns the size in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small buffers. If not, do you mind adding it? To quote this two: [ include/drm/drm_vma_manager.h ] /** * drm_vma_node_size() - Return size (page-based) * @node: Node to inspect * * Return the size as number of pages for the given node. This is the same size * that was passed to drm_vma_offset_add(). If no offset is allocated for the * node, this is 0. * * RETURNS: * Size of @node as number of pages. 0 if the node does not have an offset * allocated. */ [ drivers/gpu/drm/drm_gem.c ] /** * drm_gem_mmap - memory map routine for GEM objects * @filp: DRM file pointer * @vma: VMA for the area to be mapped * * If a driver supports GEM object mapping, mmap calls on the DRM file * descriptor will end up here. * * Look up the GEM object based on the offset passed in (vma-vm_pgoff will * contain the fake offset we created when the GTT map ioctl was called on * the object) and map it with a call to drm_gem_mmap_obj(). */ - Sedat - Thanks in advance! - Sedat - Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch on this little fixup. -Daniel --- drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 3613b50..1f76572 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma) } obj = container_of(node, struct drm_gem_object, vma_node); - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma); + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) PAGE_SHIFT, vma); mutex_unlock(dev-struct_mutex); -- 1.8.3.4 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]
On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula wrote: > On Thu, 25 Jul 2013, Sedat Dilek wrote: >> On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek >> wrote: >>> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula >>> wrote: >>>> On Thu, 25 Jul 2013, Sedat Dilek wrote: >>>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell >>>> canb.auug.org.au> wrote: >>>>>> Hi all, >>>>>> >>>>>> Changes since 20130724: >>>>>> >>>>>> Removed tree: >>>>>> arm-dt (at maintainer's request) >>>>>> >>>>>> The wireless-next tree lost its build failure and gained a conflict >>>>>> against Linus' tree. >>>>>> >>>>>> The tty tree lost its build failure. >>>>>> >>>>>> The staging tree gained a build failure for which I disabled a driver. >>>>>> >>>>>> >>>>>> >>>>> >>>>> [ CCing drm and drm-intel folks ] >>>>> >>>>> With today's next-20130725 I see the following: >>>> >>>> Use of dev_priv->gt_lock in I915_WRITE through >>>> intel_disable_gt_powersave before spin lock init, caused by >>>> >>>> commit 181d1b9e31c668259d3798c521672afb8edd355c >>>> Author: Daniel Vetter >>>> Date: Sun Jul 21 13:16:24 2013 +0200 >>>> >>>> drm/i915: fix up gt init sequence fallout >>>> >>> >>> Ah, cool. >>> >>> I assumed/tested "drm/i915: fix the racy object accounting", but this >>> does not fix it. >>> Will try with yours. >>> >> >> Sorry, Jani. >> >> next-20130725 ships the patch you pointed, too. > > Confused. I meant that the above mentioned commit "drm/i915: fix up gt > init sequence fallout" causes the problem. The patch I included in my > mail should fix it. Could you try that please? > [ Note2myself: Do not read half of the message... ] The bad... Your patch needed some refresh against next-20130725 (guess it's against drm-intel-nightly). The good... YES, your patch fixes the issue for me! The ugly... /me. Feel free to add my: Tested-by: Sedat Dilek Thanks for the quick fix! - Sedat - - Sedat - > BR, > Jani. > > > >> >> - Sedat - >> >> [1] >> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130725=grep=drm%2Fi915%3A+fix+up+gt+init+sequence+fallout >> [2] >> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=181d1b9e31c668259d3798c521672afb8edd355c >> > > -- > Jani Nikula, Intel Open Source Technology Center -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-rc2-next20130725-4-iniza-small (sedat.dilek at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Thu Jul 25 12:31:29 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz.next root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable [0.00] BIOS-e820: [mem 0xd9c9f000-0xdae7efff] reserved [0.00] BIOS-e820: [mem 0xdae7f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x00
[Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]
On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
> wrote:
>> On Thu, 25 Jul 2013, Sedat Dilek wrote:
>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell
>>> wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20130724:
>>>>
>>>> Removed tree:
>>>> arm-dt (at maintainer's request)
>>>>
>>>> The wireless-next tree lost its build failure and gained a conflict
>>>> against Linus' tree.
>>>>
>>>> The tty tree lost its build failure.
>>>>
>>>> The staging tree gained a build failure for which I disabled a driver.
>>>>
>>>>
>>>>
>>>
>>> [ CCing drm and drm-intel folks ]
>>>
>>> With today's next-20130725 I see the following:
>>
>> Use of dev_priv->gt_lock in I915_WRITE through
>> intel_disable_gt_powersave before spin lock init, caused by
>>
>> commit 181d1b9e31c668259d3798c521672afb8edd355c
>> Author: Daniel Vetter
>> Date: Sun Jul 21 13:16:24 2013 +0200
>>
>> drm/i915: fix up gt init sequence fallout
>>
>
> Ah, cool.
>
> I assumed/tested "drm/i915: fix the racy object accounting", but this
> does not fix it.
> Will try with yours.
>
Sorry, Jani.
next-20130725 ships the patch you pointed, too.
- Sedat -
[1]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130725=grep=drm%2Fi915%3A+fix+up+gt+init+sequence+fallout
[2]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=181d1b9e31c668259d3798c521672afb8edd355c
> - Sedat -
>
> [1]
> cgit.freedesktop.org/~danvet/drm-intel/patch/?id=190426c5a60659533b9361b7e0ba083bd5434c80
>
>> Daniel, how about just doing this (untested):
>>
>> Cheers,
>> Jani.
>>
>>
>> From a6b46053ba07d2e129691fd24ad2e43a1d8dfd10 Mon Sep 17 00:00:00 2001
>> From: Jani Nikula
>> Date: Thu, 25 Jul 2013 12:40:31 +0300
>> Subject: [PATCH] drm/i915: initialize gt_lock early with other spin locks
>> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
>> Cc: Jani Nikula
>>
>> commit 181d1b9e31c668259d3798c521672afb8edd355c
>> Author: Daniel Vetter
>> Date: Sun Jul 21 13:16:24 2013 +0200
>>
>> drm/i915: fix up gt init sequence fallout
>>
>> moved dev_priv->gt_lock initialization after use. Do the initialization
>> much earlier with other spin lock initializations.
>>
>> Reported-by: Sedat Dilek
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/i915_dma.c |1 +
>> drivers/gpu/drm/i915/intel_pm.c |2 --
>> 2 files changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index 67ec54f..b064a5a 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1496,6 +1496,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
>> long flags)
>> dev_priv->info = info;
>>
>> spin_lock_init(_priv->irq_lock);
>> + spin_lock_init(_priv->gt_lock);
>> spin_lock_init(_priv->gpu_error.lock);
>> spin_lock_init(_priv->rps.lock);
>> spin_lock_init(_priv->backlight.lock);
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 6a347f5..51a2a60 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -5497,8 +5497,6 @@ void intel_gt_init(struct drm_device *dev)
>> {
>> struct drm_i915_private *dev_priv = dev->dev_private;
>>
>> - spin_lock_init(_priv->gt_lock);
>> -
>> if (IS_VALLEYVIEW(dev)) {
>> dev_priv->gt.force_wake_get = vlv_force_wake_get;
>> dev_priv->gt.force_wake_put = vlv_force_wake_put;
>> --
>> 1.7.9.5
>>
>>
>>
>>>
>>> [ 17.122627] [drm] Memory usable by graphics device = 2048M
>>> [ 17.122639] i915 :00:02.0: setting latency timer to 64
>>> [ 17.164740] BUG: spinlock bad magic on CPU#3, modprobe/635
>>> [ 17.164797] lock: 0x8800bc534040, .magic: , .owner:
>>> /-1, .owner_cpu: 0
>>> [ 17.164856] CPU: 3 PID: 635 Comm: modprobe Not tainted
>>> 3.11.0-rc2-next20130725-1-iniza-small #1
>>> [ 17.164914] Hardware n
[Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]
On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
wrote:
> On Thu, 25 Jul 2013, Sedat Dilek wrote:
>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> Changes since 20130724:
>>>
>>> Removed tree:
>>> arm-dt (at maintainer's request)
>>>
>>> The wireless-next tree lost its build failure and gained a conflict
>>> against Linus' tree.
>>>
>>> The tty tree lost its build failure.
>>>
>>> The staging tree gained a build failure for which I disabled a driver.
>>>
>>>
>>>
>>
>> [ CCing drm and drm-intel folks ]
>>
>> With today's next-20130725 I see the following:
>
> Use of dev_priv->gt_lock in I915_WRITE through
> intel_disable_gt_powersave before spin lock init, caused by
>
> commit 181d1b9e31c668259d3798c521672afb8edd355c
> Author: Daniel Vetter
> Date: Sun Jul 21 13:16:24 2013 +0200
>
> drm/i915: fix up gt init sequence fallout
>
Ah, cool.
I assumed/tested "drm/i915: fix the racy object accounting", but this
does not fix it.
Will try with yours.
- Sedat -
[1]
cgit.freedesktop.org/~danvet/drm-intel/patch/?id=190426c5a60659533b9361b7e0ba083bd5434c80
> Daniel, how about just doing this (untested):
>
> Cheers,
> Jani.
>
>
> From a6b46053ba07d2e129691fd24ad2e43a1d8dfd10 Mon Sep 17 00:00:00 2001
> From: Jani Nikula
> Date: Thu, 25 Jul 2013 12:40:31 +0300
> Subject: [PATCH] drm/i915: initialize gt_lock early with other spin locks
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> Cc: Jani Nikula
>
> commit 181d1b9e31c668259d3798c521672afb8edd355c
> Author: Daniel Vetter
> Date: Sun Jul 21 13:16:24 2013 +0200
>
> drm/i915: fix up gt init sequence fallout
>
> moved dev_priv->gt_lock initialization after use. Do the initialization
> much earlier with other spin lock initializations.
>
> Reported-by: Sedat Dilek
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_dma.c |1 +
> drivers/gpu/drm/i915/intel_pm.c |2 --
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 67ec54f..b064a5a 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1496,6 +1496,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> dev_priv->info = info;
>
> spin_lock_init(_priv->irq_lock);
> + spin_lock_init(_priv->gt_lock);
> spin_lock_init(_priv->gpu_error.lock);
> spin_lock_init(_priv->rps.lock);
> spin_lock_init(_priv->backlight.lock);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6a347f5..51a2a60 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5497,8 +5497,6 @@ void intel_gt_init(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - spin_lock_init(_priv->gt_lock);
> -
> if (IS_VALLEYVIEW(dev)) {
> dev_priv->gt.force_wake_get = vlv_force_wake_get;
> dev_priv->gt.force_wake_put = vlv_force_wake_put;
> --
> 1.7.9.5
>
>
>
>>
>> [ 17.122627] [drm] Memory usable by graphics device = 2048M
>> [ 17.122639] i915 :00:02.0: setting latency timer to 64
>> [ 17.164740] BUG: spinlock bad magic on CPU#3, modprobe/635
>> [ 17.164797] lock: 0x8800bc534040, .magic: , .owner:
>> /-1, .owner_cpu: 0
>> [ 17.164856] CPU: 3 PID: 635 Comm: modprobe Not tainted
>> 3.11.0-rc2-next20130725-1-iniza-small #1
>> [ 17.164914] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [ 17.164977] 8800c0fa1738 816ddfc9
>> 0007
>> [ 17.165101] 8800bc534040 8800c0fa1758 816de065
>> 8800bc534040
>> [ 17.165222] 81a5f497 8800c0fa1778 816de08b
>> 8800bc534040
>> [ 17.165345] Call Trace:
>> [ 17.165386] [] dump_stack+0x46/0x58
>> [ 17.165428] [] spin_dump+0x8a/0x8f
>> [ 17.165469] [] spin_bug+0x21/0x26
>> [ 17.165511] [] do_raw_spin_lock+0x84/0x120
>> [ 17.165554] [] _raw_spin_lock_irqsave+0x24/0x30
>> [ 17.165620] [] i915_write32+0x36/0x150 [i915]
>> [ 17.165690] []
>> intel_disable_gt_powersave+0xf5/0x360 [i915]
>> [
linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]
On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130724: > > Removed tree: > arm-dt (at maintainer's request) > > The wireless-next tree lost its build failure and gained a conflict > against Linus' tree. > > The tty tree lost its build failure. > > The staging tree gained a build failure for which I disabled a driver. > > > [ CCing drm and drm-intel folks ] With today's next-20130725 I see the following: [ 17.122627] [drm] Memory usable by graphics device = 2048M [ 17.122639] i915 :00:02.0: setting latency timer to 64 [ 17.164740] BUG: spinlock bad magic on CPU#3, modprobe/635 [ 17.164797] lock: 0x8800bc534040, .magic: , .owner: /-1, .owner_cpu: 0 [ 17.164856] CPU: 3 PID: 635 Comm: modprobe Not tainted 3.11.0-rc2-next20130725-1-iniza-small #1 [ 17.164914] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 17.164977] 8800c0fa1738 816ddfc9 0007 [ 17.165101] 8800bc534040 8800c0fa1758 816de065 8800bc534040 [ 17.165222] 81a5f497 8800c0fa1778 816de08b 8800bc534040 [ 17.165345] Call Trace: [ 17.165386] [] dump_stack+0x46/0x58 [ 17.165428] [] spin_dump+0x8a/0x8f [ 17.165469] [] spin_bug+0x21/0x26 [ 17.165511] [] do_raw_spin_lock+0x84/0x120 [ 17.165554] [] _raw_spin_lock_irqsave+0x24/0x30 [ 17.165620] [] i915_write32+0x36/0x150 [i915] [ 17.165690] [] intel_disable_gt_powersave+0xf5/0x360 [i915] [ 17.165768] [] intel_gt_sanitize+0x49/0xb0 [i915] [ 17.165827] [] i915_driver_load+0x638/0xed0 [i915] [ 17.165886] [] drm_get_pci_dev+0x181/0x2a0 [drm] [ 17.165929] [] ? do_raw_spin_unlock+0x5d/0xb0 [ 17.165987] [] i915_pci_probe+0x36/0x70 [i915] [ 17.166031] [] local_pci_probe+0x4b/0x80 [ 17.166073] [] pci_device_probe+0x101/0x120 [ 17.166115] [] driver_probe_device+0x7b/0x240 [ 17.166158] [] __driver_attach+0xab/0xb0 [ 17.166200] [] ? driver_probe_device+0x240/0x240 [ 17.166244] [] bus_for_each_dev+0x5e/0x90 [ 17.166286] [] driver_attach+0x1e/0x20 [ 17.166330] [] bus_add_driver+0x104/0x270 [ 17.166372] [] driver_register+0x7d/0x160 [ 17.166415] [] __pci_register_driver+0x64/0x70 [ 17.166460] [] ? 0xa0445fff [ 17.166510] [] drm_pci_init+0x11a/0x130 [drm] [ 17.166553] [] ? 0xa0445fff [ 17.166610] [] i915_init+0x66/0x68 [i915] [ 17.166652] [] do_one_initcall+0x4e/0x180 [ 17.166696] [] ? set_memory_nx+0x43/0x50 [ 17.166742] [] load_module+0x209c/0x25b0 [ 17.166784] [] ? show_initstate+0x50/0x50 [ 17.166827] [] SyS_init_module+0xac/0xd0 [ 17.166871] [] tracesys+0xe1/0xe6 [ 17.167649] i915 :00:02.0: irq 49 for MSI/MSI-X [ 17.167709] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 17.167753] [drm] Driver supports precise vblank timestamp query. I can't say what is the root cause and when it occured for the 1st time (my last Linux-next release was next-20130709). Please, see also attached kernel-config and full dmesg. - Sedat - -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-rc2-next20130725-1-iniza-small (sedat.dilek at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Thu Jul 25 09:03:18 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz.next root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable [0.00] BIOS-e820: [mem 0xd9c9f000-0xdae7efff] reserved [0.00] BIOS-e820: [mem 0xdae7f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved [0.00] BIOS-e820: [mem
Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130628: The regulator tree gained a build failure so I used the version from next-20130628. The trivial tree gained a conflict against the fbdev tree. The arm-soc tree gained a conflict against the net-next tree. The akpm tree lost a few patches that turned up elsewhere and I removed 2 that were causing run time problems. [ CC drm and drm-intel folks ] [ Did not check any relevant MLs ] Please, see attached dmesg output. Clock mismatch, one for Jesse to figure out. Note that this patch is for 3.12, I simply haven't yet gotten around to properly split my patch queue so a few spilled into -next. I'll do that now. I like lightspeed-fast replies :-). Guess drm/i915: get mode clock when reading the pipe config v9 [1] is the cause. Problem solved by applying these patches to next-20130701 from intel-gfx patchwork-service [0]: [1/2] drm/i915: fixup messages in pipe_config_compare [2/2] drm/i915: get clock config when checking CRTC state too AFAICS 2/2 was folded into updated drm/i915: get mode clock when reading the pipe config v9 [3]. It would be kind to be CCed on the patches and get also some credits. Also a CC to the report in linux-next should IMHO be done. - Sedat - [0] https://patchwork.kernel.org/project/intel-gfx/list/ [1] https://patchwork.kernel.org/patch/2809031/ [2] https://patchwork.kernel.org/patch/2809021/ [3] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightlyid=f1f644dc66cbaf5a4c7dcde683361536b41885b9 - Sedat - [1] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queuedid=d325d8b4f351f9d45e7c8baabf581fd21f343133 -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek wrote: > On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter > wrote: >> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek >> wrote: >>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell >>> wrote: >>>> Hi all, >>>> >>>> Changes since 20130628: >>>> >>>> The regulator tree gained a build failure so I used the version from >>>> next-20130628. >>>> >>>> The trivial tree gained a conflict against the fbdev tree. >>>> >>>> The arm-soc tree gained a conflict against the net-next tree. >>>> >>>> The akpm tree lost a few patches that turned up elsewhere and I removed 2 >>>> that were causing run time problems. >>>> >>> >>> [ CC drm and drm-intel folks ] >>> >>> [ Did not check any relevant MLs ] >>> >>> Please, see attached dmesg output. >> >> Clock mismatch, one for Jesse to figure out. Note that this patch is >> for 3.12, I simply haven't yet gotten around to properly split my >> patch queue so a few spilled into -next. I'll do that now. > > I like lightspeed-fast replies :-). > > Guess "drm/i915: get mode clock when reading the pipe config v9" [1] > is the cause. > Problem solved by applying these patches to next-20130701 from intel-gfx patchwork-service [0]: [1/2] drm/i915: fixup messages in pipe_config_compare [2/2] drm/i915: get clock config when checking CRTC state too AFAICS 2/2 was folded into updated "drm/i915: get mode clock when reading the pipe config v9" [3]. It would be kind to be CCed on the patches and get also some credits. Also a CC to the report in linux-next should IMHO be done. - Sedat - [0] https://patchwork.kernel.org/project/intel-gfx/list/ [1] https://patchwork.kernel.org/patch/2809031/ [2] https://patchwork.kernel.org/patch/2809021/ [3] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightly=f1f644dc66cbaf5a4c7dcde683361536b41885b9 > - Sedat - > > [1] > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued=d325d8b4f351f9d45e7c8baabf581fd21f343133 > >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter wrote: > On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek wrote: >> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell >> wrote: >>> Hi all, >>> >>> Changes since 20130628: >>> >>> The regulator tree gained a build failure so I used the version from >>> next-20130628. >>> >>> The trivial tree gained a conflict against the fbdev tree. >>> >>> The arm-soc tree gained a conflict against the net-next tree. >>> >>> The akpm tree lost a few patches that turned up elsewhere and I removed 2 >>> that were causing run time problems. >>> >> >> [ CC drm and drm-intel folks ] >> >> [ Did not check any relevant MLs ] >> >> Please, see attached dmesg output. > > Clock mismatch, one for Jesse to figure out. Note that this patch is > for 3.12, I simply haven't yet gotten around to properly split my > patch queue so a few spilled into -next. I'll do that now. I like lightspeed-fast replies :-). Guess "drm/i915: get mode clock when reading the pipe config v9" [1] is the cause. - Sedat - [1] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued=d325d8b4f351f9d45e7c8baabf581fd21f343133 > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130628: > > The regulator tree gained a build failure so I used the version from > next-20130628. > > The trivial tree gained a conflict against the fbdev tree. > > The arm-soc tree gained a conflict against the net-next tree. > > The akpm tree lost a few patches that turned up elsewhere and I removed 2 > that were causing run time problems. > [ CC drm and drm-intel folks ] [ Did not check any relevant MLs ] Please, see attached dmesg output. - Sedat - -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.10.0-next20130701-1-iniza-small (sedat.dilek at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Mon Jul 1 10:37:36 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz.next root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable [0.00] BIOS-e820: [mem 0xd9c9f000-0xdae7efff] reserved [0.00] BIOS-e820: [mem 0xdae7f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffd8-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x11fe00 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0C000 mask FE000 write-back [0.00] 3 base 0DC00 mask FFC00 uncachable [0.00] 4 base 0DB00 mask FFF00 uncachable [0.00] 5 base 1 mask FE000 write-back [0.00] 6 base 11FE0 mask FFFE0 uncachable [0.00] 7 base 0FFC0 mask FFFC0 write-protect [0.00] 8 disabled [0.00] 9 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xdb000 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f00e0-0x000f00ef] mapped at [880f00e0] [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] reserving inaccessible SNB gfx pages [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x0204b000, 0x0204bfff] PGTABLE [0.00] BRK [0x0204c000, 0x0204cfff] PGTABLE [0.00] BRK [0x0204d000, 0x0204dfff] PGTABLE [0.00] init_memory_mapping: [mem 0x11fc0-0x11fdf] [0.00] [mem 0x11fc0-0x11fdf] page 2M [
Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130628: The regulator tree gained a build failure so I used the version from next-20130628. The trivial tree gained a conflict against the fbdev tree. The arm-soc tree gained a conflict against the net-next tree. The akpm tree lost a few patches that turned up elsewhere and I removed 2 that were causing run time problems. [ CC drm and drm-intel folks ] [ Did not check any relevant MLs ] Please, see attached dmesg output. Clock mismatch, one for Jesse to figure out. Note that this patch is for 3.12, I simply haven't yet gotten around to properly split my patch queue so a few spilled into -next. I'll do that now. I like lightspeed-fast replies :-). Guess drm/i915: get mode clock when reading the pipe config v9 [1] is the cause. - Sedat - [1] http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queuedid=d325d8b4f351f9d45e7c8baabf581fd21f343133 -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Tree for Jun 28 [ call-trace: workqueue | drm releated? ]
On Fri, Jun 28, 2013 at 11:21 AM, Sedat Dilek wrote: > On Fri, Jun 28, 2013 at 10:31 AM, Sedat Dilek > wrote: >> On Fri, Jun 28, 2013 at 10:29 AM, Dave Airlie wrote: >>>> >>>> [ CC wq and drm(-intel) folks ] >>>> >>> >>> Already know the commit which caused it, mentioned on dri-devel, >>> waiting for danvet to wake up and look, before I revert it later. >>> >> >> Thanks, I like fast responses. >> >> For followers... See "workqueue warnings in helper code" >> >> - Sedat - >> >> http://lists.freedesktop.org/archives/dri-devel/2013-June/040707.html >> > > Just FYI: > > Daniel decided to revert [2] (see [1]). > > commit 160954b7bca43da7cd3cfbce310e6df919a8216e > "drm: kms_helper: don't lose hotplug event" > I have tested that with my -2 build and the call-traces are gone. Feel free to add my Reported-by/Tested-by. - Sedat - > - Sedat - > > [1] http://lists.freedesktop.org/archives/dri-devel/2013-June/040721.html > [2] > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=160954b7bca43da7cd3cfbce310e6df919a8216e > >>> Dave.
linux-next: Tree for Jun 28 [ call-trace: workqueue | drm releated? ]
On Fri, Jun 28, 2013 at 10:31 AM, Sedat Dilek wrote: > On Fri, Jun 28, 2013 at 10:29 AM, Dave Airlie wrote: >>> >>> [ CC wq and drm(-intel) folks ] >>> >> >> Already know the commit which caused it, mentioned on dri-devel, >> waiting for danvet to wake up and look, before I revert it later. >> > > Thanks, I like fast responses. > > For followers... See "workqueue warnings in helper code" > > - Sedat - > > http://lists.freedesktop.org/archives/dri-devel/2013-June/040707.html > Just FYI: Daniel decided to revert [2] (see [1]). commit 160954b7bca43da7cd3cfbce310e6df919a8216e "drm: kms_helper: don't lose hotplug event" - Sedat - [1] http://lists.freedesktop.org/archives/dri-devel/2013-June/040721.html [2] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=160954b7bca43da7cd3cfbce310e6df919a8216e >> Dave.
linux-next: Tree for Jun 28 [ call-trace: workqueue | drm releated? ]
On Fri, Jun 28, 2013 at 10:29 AM, Dave Airlie wrote: >> >> [ CC wq and drm(-intel) folks ] >> > > Already know the commit which caused it, mentioned on dri-devel, > waiting for danvet to wake up and look, before I revert it later. > Thanks, I like fast responses. For followers... See "workqueue warnings in helper code" - Sedat - http://lists.freedesktop.org/archives/dri-devel/2013-June/040707.html > Dave.
linux-next: Tree for Jun 28 [ call-trace: workqueue | drm releated? ]
On Fri, Jun 28, 2013 at 9:33 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20130627: > > This tree produces the following warning when built for many (all?) > configs (it has been fixed in the drm tree): > > drivers/video/Kconfig:42:error: recursive dependency detected! > drivers/video/Kconfig:42: symbol FB is selected by DRM_KMS_HELPER > drivers/gpu/drm/Kconfig:29: symbol DRM_KMS_HELPER is selected by DRM_OMAP > drivers/gpu/drm/omapdrm/Kconfig:2: symbol DRM_OMAP depends on FB_OMAP2 > drivers/video/omap2/omapfb/Kconfig:1: symbol FB_OMAP2 depends on FB > > The arm-soc tree gained a conflict against the mfd tree. > > I applied a patch to the akpm tree to remove a lot of warnings. > > > [ CC wq and drm(-intel) folks ] With next-20130628 I see the following call-trace: [ 11.941618] [ cut here ] [ 11.941624] WARNING: CPU: 0 PID: 675 at kernel/workqueue.c:1445 __queue_delayed_work+0x18c/0x1a0() [ 11.941626] Modules linked in: i915(+) snd_page_alloc iwlwifi snd_seq_midi snd_seq_midi_event btusb psmouse snd_rawmidi snd_seq bluetooth cfg80211 i2c_algo_bit snd_timer samsung_laptop serio_raw snd_seq_device drm_kms_helper lpc_ich drm snd wmi mac_hid soundcore video lp parport hid_generic usbhid hid usb_storage r8169 mii [ 11.941651] CPU: 0 PID: 675 Comm: modprobe Not tainted 3.10.0-rc7-next20130628-1-iniza-small #1 [ 11.941653] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 11.941655] 05a5 88010b5596a8 816db223 1908 [ 11.941658] 88010b5596e8 810661cc a00d3341 [ 11.941661] 0100 880119e72000 88010765a000 0003 [ 11.941664] Call Trace: [ 11.941671] [] dump_stack+0x46/0x58 [ 11.941675] [] warn_slowpath_common+0x8c/0xc0 [ 11.941679] [] warn_slowpath_null+0x1a/0x20 [ 11.941682] [] __queue_delayed_work+0x18c/0x1a0 [ 11.941685] [] queue_delayed_work_on+0x4d/0x60 [ 11.941691] [] drm_helper_probe_single_connector_modes+0x270/0x420 [drm_kms_helper] [ 11.941696] [] drm_fb_helper_initial_config+0x1c2/0x550 [drm_kms_helper] [ 11.941700] [] ? drm_fb_helper_single_add_all_connectors+0x81/0xe0 [drm_kms_helper] [ 11.941705] [] ? kmem_cache_alloc_trace+0x1bc/0x1f0 [ 11.941725] [] ? i915_write32+0x81/0x130 [i915] [ 11.941748] [] intel_fbdev_initial_config+0x21/0x30 [i915] [ 11.941763] [] i915_driver_load+0xe32/0xe60 [i915] [ 11.941777] [] drm_get_pci_dev+0x181/0x2a0 [drm] [ 11.941781] [] ? do_raw_spin_unlock+0x5d/0xb0 [ 11.941794] [] i915_pci_probe+0x36/0x70 [i915] [ 11.941799] [] local_pci_probe+0x4b/0x80 [ 11.941801] [] pci_device_probe+0x101/0x120 [ 11.941806] [] driver_probe_device+0x7b/0x240 [ 11.941809] [] __driver_attach+0xab/0xb0 [ 11.941813] [] ? driver_probe_device+0x240/0x240 [ 11.941816] [] bus_for_each_dev+0x5e/0x90 [ 11.941819] [] driver_attach+0x1e/0x20 [ 11.941823] [] bus_add_driver+0x104/0x270 [ 11.941826] [] driver_register+0x7d/0x160 [ 11.941830] [] __pci_register_driver+0x64/0x70 [ 11.941833] [] ? 0xa02edfff [ 11.941842] [] drm_pci_init+0x11a/0x130 [drm] [ 11.941844] [] ? 0xa02edfff [ 11.941858] [] i915_init+0x66/0x68 [i915] [ 11.941861] [] do_one_initcall+0x4e/0x180 [ 11.941865] [] ? set_memory_nx+0x43/0x50 [ 11.941869] [] load_module+0x1cf9/0x2620 [ 11.941872] [] ? show_initstate+0x50/0x50 [ 11.941875] [] SyS_init_module+0xac/0xd0 [ 11.941879] [] tracesys+0xe1/0xe6 [ 11.941881] ---[ end trace a06c6f52b0f09abe ]--- My dmesg and kernel-config are attached. ( I have seen there were new commits in drm-next which did not hit today'n -next. ) - Sedat - -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.10.0-rc7-next20130628-1-iniza-small (sedat.dilek at gmail.com@fambox) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP Fri Jun 28 09:56:38 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz.next root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00]
Re: linux-next: Tree for Jun 28 [ call-trace: workqueue | drm releated? ]
On Fri, Jun 28, 2013 at 10:29 AM, Dave Airlie airl...@gmail.com wrote: [ CC wq and drm(-intel) folks ] Already know the commit which caused it, mentioned on dri-devel, waiting for danvet to wake up and look, before I revert it later. Thanks, I like fast responses. For followers... See workqueue warnings in helper code - Sedat - http://lists.freedesktop.org/archives/dri-devel/2013-June/040707.html Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Jun 28 [ call-trace: workqueue | drm releated? ]
On Fri, Jun 28, 2013 at 10:31 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:29 AM, Dave Airlie airl...@gmail.com wrote: [ CC wq and drm(-intel) folks ] Already know the commit which caused it, mentioned on dri-devel, waiting for danvet to wake up and look, before I revert it later. Thanks, I like fast responses. For followers... See workqueue warnings in helper code - Sedat - http://lists.freedesktop.org/archives/dri-devel/2013-June/040707.html Just FYI: Daniel decided to revert [2] (see [1]). commit 160954b7bca43da7cd3cfbce310e6df919a8216e drm: kms_helper: don't lose hotplug event - Sedat - [1] http://lists.freedesktop.org/archives/dri-devel/2013-June/040721.html [2] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=160954b7bca43da7cd3cfbce310e6df919a8216e Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Jun 28 [ call-trace: workqueue | drm releated? ]
On Fri, Jun 28, 2013 at 11:21 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:31 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:29 AM, Dave Airlie airl...@gmail.com wrote: [ CC wq and drm(-intel) folks ] Already know the commit which caused it, mentioned on dri-devel, waiting for danvet to wake up and look, before I revert it later. Thanks, I like fast responses. For followers... See workqueue warnings in helper code - Sedat - http://lists.freedesktop.org/archives/dri-devel/2013-June/040707.html Just FYI: Daniel decided to revert [2] (see [1]). commit 160954b7bca43da7cd3cfbce310e6df919a8216e drm: kms_helper: don't lose hotplug event I have tested that with my -2 build and the call-traces are gone. Feel free to add my Reported-by/Tested-by. - Sedat - - Sedat - [1] http://lists.freedesktop.org/archives/dri-devel/2013-June/040721.html [2] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=160954b7bca43da7cd3cfbce310e6df919a8216e Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the final tree (drm-intel tree related)
On Tue, Mar 12, 2013 at 10:50 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook keesc...@chromium.org wrote: On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the final tree, today's linux-next build (i386 defconfig) failed like this: drivers/built-in.o: In function `i915_min_freq_set': i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3' drivers/built-in.o: In function `i915_max_freq_set': i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3' Caused by commit 2389cc500686 (drm/i915: use simple attribute in debugfs routines) from the drm-intel tree. I have reverted that commit for today. Ah-ha, thanks. I've sent a follow-up patch to fix this. Can you please point to the patch [1] next time? Thanks. - Sedat - [1] https://patchwork.kernel.org/patch/2253231/ Hi Kees, Hi Daniel, was the above patch merged into drm (for me it does not look like it was [1])? Regards, - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=authorq=Kees+Cook -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-next in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the final tree (drm-intel tree related)
On Tue, Mar 12, 2013 at 10:50 AM, Sedat Dilek wrote:
> On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook wrote:
>> On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> After merging the final tree, today's linux-next build (i386 defconfig)
>>> failed like this:
>>>
>>> drivers/built-in.o: In function `i915_min_freq_set':
>>> i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3'
>>> drivers/built-in.o: In function `i915_max_freq_set':
>>> i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3'
>>>
>>> Caused by commit 2389cc500686 ("drm/i915: use simple attribute in debugfs
>>> routines") from the drm-intel tree.
>>>
>>> I have reverted that commit for today.
>>
>> Ah-ha, thanks. I've sent a follow-up patch to fix this.
>>
>
> Can you please point to the patch [1] next time?
> Thanks.
>
> - Sedat -
>
> [1] https://patchwork.kernel.org/patch/2253231/
>
Hi Kees, Hi Daniel,
was the above patch merged into drm (for me it does not look like it was [1])?
Regards,
- Sedat -
[1]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=author=Kees+Cook
>> -Kees
>>
>> --
>> Kees Cook
>> Chrome OS Security
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-next" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: build failure after merge of the final tree (drm-intel tree related)
On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook wrote:
> On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the final tree, today's linux-next build (i386 defconfig)
>> failed like this:
>>
>> drivers/built-in.o: In function `i915_min_freq_set':
>> i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3'
>> drivers/built-in.o: In function `i915_max_freq_set':
>> i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3'
>>
>> Caused by commit 2389cc500686 ("drm/i915: use simple attribute in debugfs
>> routines") from the drm-intel tree.
>>
>> I have reverted that commit for today.
>
> Ah-ha, thanks. I've sent a follow-up patch to fix this.
>
Can you please point to the patch [1] next time?
Thanks.
- Sedat -
[1] https://patchwork.kernel.org/patch/2253231/
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: build failure after merge of the final tree (drm-intel tree related)
On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook keesc...@chromium.org wrote: On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the final tree, today's linux-next build (i386 defconfig) failed like this: drivers/built-in.o: In function `i915_min_freq_set': i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3' drivers/built-in.o: In function `i915_max_freq_set': i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3' Caused by commit 2389cc500686 (drm/i915: use simple attribute in debugfs routines) from the drm-intel tree. I have reverted that commit for today. Ah-ha, thanks. I've sent a follow-up patch to fix this. Can you please point to the patch [1] next time? Thanks. - Sedat - [1] https://patchwork.kernel.org/patch/2253231/ -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-next in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:59 PM, Sedat Dilek wrote:
> On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni wrote:
>> Hi
>>
>> 2013/2/28 Sedat Dilek :
>>> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek
>>> wrote:
>>>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> 2013/2/28 Chris Wilson :
>>>>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>>>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek >>>>>> gmail.com> wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > I am seeing this also on Linux-Next.
>>>>>>> >
>>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>>> > (has irq: 1)!
>>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>>> > (has irq: 1)!
>>>>>>> >
>>>>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>>> > (has irq: 1)!
>>>>>>> >
>>>>>>> > This seems to be hard reproducible...
>>>>>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>>>>>> >
>>>>>>> > Is there a way to force the error?
>>>>>>> >
>>>>>>> > Possible patch see [1].
>>>>>>> >
>>>>>>> > - Sedat -
>>>>>>> >
>>>>>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>>>>>
>>>>>> That was:
>>>>>>
>>>>>> + if (!done) {
>>>>>> + status = I915_READ_NOTRACE(ch_ctl);
>>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>>>>> %i), status=%08x!\n",
>>>>>> + has_aux_irq, status);
>>>>>> + }
>>>>>>
>>>>>> You applied
>>>>>>
>>>>>> + if (!done) {
>>>>>> + status = I915_READ_NOTRACE(ch_ctl);
>>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>>>>> %i), status=%08x!\n",
>>>>>> + has_aux_irq, status);
>>>>>> + {
>>>>>
>>>>> In addition to this, after the problem happens can you please dump the
>>>>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>>>>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>>>>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>>>>> I915_READ(0xC4008).
>>>>>
>>>>
>>>> Do I need a specific version of intel-gpu-tools?
>>>> Ubuntu/precise has v1.2 in its archives - sufficient?
>>>> Note: The error was twice after dozenz of Linux-Next kernel builds.
>>>>
>>>> - Sedat -
>>>>
>>>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>>>>
>>>
>>> Installed intel-gpu-tools.
>>>
>>> # intel_reg_read
>>> Usage: intel_reg_read [-f | addr]
>>> -f : read back full range of registers.
>>> WARNING! This could be danger to hang the machine!
>>> addr : in 0x format
>>>
>>> # intel_reg_read 0x44008
>>> Couldn't map MMIO region: Resource temporarily unavailable
>>>
>>> [ 368.281707] intel_reg_read:3657 conflicting memory types
>>> f000-f040 uncached-minus<->write-combining
>>> [ 381.521912] intel_reg_read:3658 conflicting memory types
>>> f000-f040 uncached-minus<->write-combining
>>> [ 401.136291] intel_reg_read:3659 conflicting memory types
>>> f000-f040 uncached-minus<->write-combining
>>>
>>> Wrong i-g-t version? Missing enabled kernel-config option? Boot with
>>> i915 debug enabled?
>>
>> Just build the version from git and it should work
>> (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
>>
>
> NO.
>
> $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> intel-gpu-tools-git
>
> $ cd intel-gpu-tools-git/
>
> $ ./autogen.sh --disable-dumper <--- requires swig2.0 and python >=3.x
>
> $ sudo ./tools/intel_reg_read 0x44008
> 0x44008 : 0x0
>
> $ sudo ./tools/intel_reg_read 0xC4008
> 0xC4008 : 0x0
>
> $ sudo ./tools/intel_reg_dumper > /tmp/intel_reg_dumper.txt <--- see
> attachment
>
> Does this help you?
>
Ping Paulo.
- Sedat -
> - Sedat -
>
>
>>>
>>> - Sedat -
>>>
>>>>> If you conclude that the value of 0x44008 is 0x0 while the value of
>>>>> 0xC4008 is not, then this patch should help:
>>>>> https://patchwork.kernel.org/patch/2177841/
>>>>>
>>>>>>
>>>>>> That second '{' is the source of the compile error.
>>>>>> -Chris
>>>>>>
>>>>>> --
>>>>>> Chris Wilson, Intel Open Source Technology Centre
>>>>>> ___
>>>>>> Intel-gfx mailing list
>>>>>> Intel-gfx at lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Paulo Zanoni
>>
>>
>>
>> --
>> Paulo Zanoni
Re: [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 12:18 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com wrote:
Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
This seems to be hard reproducible...
Laptop-LCD... Sandybridge Mobile-GT2.
Is there a way to force the error?
Possible patch see [1].
- Sedat -
[1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ {
That second '{' is the source of the compile error.
Schei**e, OK I try with a v2.
A hint how to force the error?
- Sedat -
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Chris Wilson ch...@chris-wilson.co.uk:
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com wrote:
Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
This seems to be hard reproducible...
Laptop-LCD... Sandybridge Mobile-GT2.
Is there a way to force the error?
Possible patch see [1].
- Sedat -
[1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Chris Wilson ch...@chris-wilson.co.uk:
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com
wrote:
Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
This seems to be hard reproducible...
Laptop-LCD... Sandybridge Mobile-GT2.
Is there a way to force the error?
Possible patch see [1].
- Sedat -
[1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus-write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
- Sedat -
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Sedat Dilek sedat.di...@gmail.com:
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Chris Wilson ch...@chris-wilson.co.uk:
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com
wrote:
Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
This seems to be hard reproducible...
Laptop-LCD... Sandybridge Mobile-GT2.
Is there a way to force the error?
Possible patch see [1].
- Sedat -
[1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus-write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
Just build the version from git and it should work
(http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
NO.
$ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
intel-gpu-tools-git
$ cd intel-gpu-tools-git/
$ ./autogen.sh --disable-dumper --- requires swig2.0 and python =3.x
$ sudo ./tools/intel_reg_read 0x44008
0x44008 : 0x0
$ sudo ./tools/intel_reg_read 0xC4008
0xC4008 : 0x0
$ sudo ./tools/intel_reg_dumper /tmp/intel_reg_dumper.txt --- see attachment
Does this help you?
- Sedat -
- Sedat -
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
--
Paulo Zanoni
PGETBL_CTL: 0x
GEN6_INSTDONE_1: 0xfffe
GEN6_INSTDONE_2: 0x
CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
DISPLAY_PORT_PLL_BIOS_0: 0x
DISPLAY_PORT_PLL_BIOS_1: 0x
DISPLAY_PORT_PLL_BIOS_2: 0x
FDI_PLL_FREQ_CTL: 0x
PIPEACONF: 0xc010 (enabled, active, pf-pd, rotate 0,
8bpc)
HTOTAL_A: 0x05cd0555 (1366 active, 1486 total)
HBLANK_A: 0x05cd0555 (1366 start, 1486 end)
HSYNC_A: 0x05a50585 (1414 start, 1446 end)
VTOTAL_A: 0x031702ff (768 active, 792 total)
VBLANK_A: 0x031702ff (768 start, 792 end
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:59 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Sedat Dilek sedat.di...@gmail.com:
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Chris Wilson ch...@chris-wilson.co.uk:
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com
wrote:
Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
This seems to be hard reproducible...
Laptop-LCD... Sandybridge Mobile-GT2.
Is there a way to force the error?
Possible patch see [1].
- Sedat -
[1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus-write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
Just build the version from git and it should work
(http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
NO.
$ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
intel-gpu-tools-git
$ cd intel-gpu-tools-git/
$ ./autogen.sh --disable-dumper --- requires swig2.0 and python =3.x
$ sudo ./tools/intel_reg_read 0x44008
0x44008 : 0x0
$ sudo ./tools/intel_reg_read 0xC4008
0xC4008 : 0x0
$ sudo ./tools/intel_reg_dumper /tmp/intel_reg_dumper.txt --- see
attachment
Does this help you?
Ping Paulo.
- Sedat -
- Sedat -
- Sedat -
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Sedat Dilek :
>> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek
>> wrote:
>>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>>>> Hi
>>>>
>>>> 2013/2/28 Chris Wilson :
>>>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I am seeing this also on Linux-Next.
>>>>>> >
>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>> > (has irq: 1)!
>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>> > (has irq: 1)!
>>>>>> >
>>>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>>>> > (has irq: 1)!
>>>>>> >
>>>>>> > This seems to be hard reproducible...
>>>>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>>>>> >
>>>>>> > Is there a way to force the error?
>>>>>> >
>>>>>> > Possible patch see [1].
>>>>>> >
>>>>>> > - Sedat -
>>>>>> >
>>>>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>>>>
>>>>> That was:
>>>>>
>>>>> + if (!done) {
>>>>> + status = I915_READ_NOTRACE(ch_ctl);
>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>>>> %i), status=%08x!\n",
>>>>> + has_aux_irq, status);
>>>>> + }
>>>>>
>>>>> You applied
>>>>>
>>>>> + if (!done) {
>>>>> + status = I915_READ_NOTRACE(ch_ctl);
>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>>>> %i), status=%08x!\n",
>>>>> + has_aux_irq, status);
>>>>> + {
>>>>
>>>> In addition to this, after the problem happens can you please dump the
>>>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>>>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>>>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>>>> I915_READ(0xC4008).
>>>>
>>>
>>> Do I need a specific version of intel-gpu-tools?
>>> Ubuntu/precise has v1.2 in its archives - sufficient?
>>> Note: The error was twice after dozenz of Linux-Next kernel builds.
>>>
>>> - Sedat -
>>>
>>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>>>
>>
>> Installed intel-gpu-tools.
>>
>> # intel_reg_read
>> Usage: intel_reg_read [-f | addr]
>> -f : read back full range of registers.
>> WARNING! This could be danger to hang the machine!
>> addr : in 0x format
>>
>> # intel_reg_read 0x44008
>> Couldn't map MMIO region: Resource temporarily unavailable
>>
>> [ 368.281707] intel_reg_read:3657 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>> [ 381.521912] intel_reg_read:3658 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>> [ 401.136291] intel_reg_read:3659 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>>
>> Wrong i-g-t version? Missing enabled kernel-config option? Boot with
>> i915 debug enabled?
>
> Just build the version from git and it should work
> (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
>
NO.
$ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
intel-gpu-tools-git
$ cd intel-gpu-tools-git/
$ ./autogen.sh --disable-dumper <--- requires swig2.0 and python >=3.x
$ sudo ./tools/intel_reg_read 0x44008
0x44008 : 0x0
$ sudo ./tools/intel_reg_read 0xC4008
0xC4008 : 0x0
$ sudo ./tools/intel_reg_dumper &g
[Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek wrote:
> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>> Hi
>>
>> 2013/2/28 Chris Wilson :
>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > I am seeing this also on Linux-Next.
>>>> >
>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>> > (has irq: 1)!
>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>> > (has irq: 1)!
>>>> >
>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>>> > (has irq: 1)!
>>>> >
>>>> > This seems to be hard reproducible...
>>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>>> >
>>>> > Is there a way to force the error?
>>>> >
>>>> > Possible patch see [1].
>>>> >
>>>> > - Sedat -
>>>> >
>>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>>
>>> That was:
>>>
>>> + if (!done) {
>>> + status = I915_READ_NOTRACE(ch_ctl);
>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>> %i), status=%08x!\n",
>>> + has_aux_irq, status);
>>> + }
>>>
>>> You applied
>>>
>>> + if (!done) {
>>> + status = I915_READ_NOTRACE(ch_ctl);
>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>> %i), status=%08x!\n",
>>> + has_aux_irq, status);
>>> + {
>>
>> In addition to this, after the problem happens can you please dump the
>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>> I915_READ(0xC4008).
>>
>
> Do I need a specific version of intel-gpu-tools?
> Ubuntu/precise has v1.2 in its archives - sufficient?
> Note: The error was twice after dozenz of Linux-Next kernel builds.
>
> - Sedat -
>
> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus<->write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus<->write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus<->write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
- Sedat -
>> If you conclude that the value of 0x44008 is 0x0 while the value of
>> 0xC4008 is not, then this patch should help:
>> https://patchwork.kernel.org/patch/2177841/
>>
>>>
>>> That second '{' is the source of the compile error.
>>> -Chris
>>>
>>> --
>>> Chris Wilson, Intel Open Source Technology Centre
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>>
>> --
>> Paulo Zanoni
[Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Chris Wilson :
>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>>> wrote:
>>> > Hi,
>>> >
>>> > I am seeing this also on Linux-Next.
>>> >
>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> >
>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> >
>>> > This seems to be hard reproducible...
>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>> >
>>> > Is there a way to force the error?
>>> >
>>> > Possible patch see [1].
>>> >
>>> > - Sedat -
>>> >
>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>
>> That was:
>>
>> + if (!done) {
>> + status = I915_READ_NOTRACE(ch_ctl);
>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>> %i), status=%08x!\n",
>> + has_aux_irq, status);
>> + }
>>
>> You applied
>>
>> + if (!done) {
>> + status = I915_READ_NOTRACE(ch_ctl);
>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>> %i), status=%08x!\n",
>> + has_aux_irq, status);
>> + {
>
> In addition to this, after the problem happens can you please dump the
> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
> by running intel-reg-read (from intel-gpu-tools) or by changing the
> DRM_ERROR above to also print the result of I915_READ(0x44008) and
> I915_READ(0xC4008).
>
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
> If you conclude that the value of 0x44008 is 0x0 while the value of
> 0xC4008 is not, then this patch should help:
> https://patchwork.kernel.org/patch/2177841/
>
>>
>> That second '{' is the source of the compile error.
>> -Chris
>>
>> --
>> Chris Wilson, Intel Open Source Technology Centre
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
[git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 12:18 PM, Chris Wilson
wrote:
> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>> wrote:
>> > Hi,
>> >
>> > I am seeing this also on Linux-Next.
>> >
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > This seems to be hard reproducible...
>> > Laptop-LCD... Sandybridge Mobile-GT2.
>> >
>> > Is there a way to force the error?
>> >
>> > Possible patch see [1].
>> >
>> > - Sedat -
>> >
>> > [1] https://patchwork.kernel.org/patch/2192721/
>
> That was:
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + }
>
> You applied
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + {
>
> That second '{' is the source of the compile error.
Schei**e, OK I try with a v2.
A hint how to force the error?
- Sedat -
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
[git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek wrote: > Hi, > > I am seeing this also on Linux-Next. > > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > This seems to be hard reproducible... > Laptop-LCD... Sandybridge Mobile-GT2. > > Is there a way to force the error? > > Possible patch see [1]. > > - Sedat - > > [1] https://patchwork.kernel.org/patch/2192721/ Hmm, I tried to apply the test-patch against next-20130227 and it fails building the i915 kernel-module. - Sedat - -- next part -- LD drivers/gpu/drm/i915/built-in.o CC [M] drivers/gpu/drm/i915/i915_drv.o CC [M] drivers/gpu/drm/i915/i915_dma.o CC [M] drivers/gpu/drm/i915/i915_irq.o CC [M] drivers/gpu/drm/i915/i915_debugfs.o CC [M] drivers/gpu/drm/i915/i915_suspend.o CC [M] drivers/gpu/drm/i915/i915_gem.o CC [M] drivers/gpu/drm/i915/i915_gem_context.o CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CC [M] drivers/gpu/drm/i915/i915_sysfs.o CC [M] drivers/gpu/drm/i915/i915_trace_points.o CC [M] drivers/gpu/drm/i915/i915_ums.o CC [M] drivers/gpu/drm/i915/intel_display.o CC [M] drivers/gpu/drm/i915/intel_crt.o CC [M] drivers/gpu/drm/i915/intel_lvds.o CC [M] drivers/gpu/drm/i915/intel_bios.o CC [M] drivers/gpu/drm/i915/intel_ddi.o CC [M] drivers/gpu/drm/i915/intel_dp.o drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_aux_wait_done': drivers/gpu/drm/i915/intel_dp.c:352:1: error: invalid storage class for function 'intel_dp_aux_ch' drivers/gpu/drm/i915/intel_dp.c:351:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/gpu/drm/i915/intel_dp.c:492:1: error: invalid storage class for function 'intel_dp_aux_native_write' drivers/gpu/drm/i915/intel_dp.c:525:1: error: invalid storage class for function 'intel_dp_aux_native_write_1' drivers/gpu/drm/i915/intel_dp.c:533:1: error: invalid storage class for function 'intel_dp_aux_native_read' drivers/gpu/drm/i915/intel_dp.c:572:1: error: invalid storage class for function 'intel_dp_i2c_aux_ch' drivers/gpu/drm/i915/intel_dp.c:669:1: error: invalid storage class for function 'intel_dp_i2c_init' drivers/gpu/drm/i915/intel_dp.c:845:13: error: invalid storage class for function 'ironlake_set_pll_edp' drivers/gpu/drm/i915/intel_dp.c:872:1: error: invalid storage class for function 'intel_dp_mode_set' drivers/gpu/drm/i915/intel_dp.c:985:13: error: invalid storage class for function 'ironlake_wait_panel_status' drivers/gpu/drm/i915/intel_dp.c:1004:13: error: invalid storage class for function 'ironlake_wait_panel_on' drivers/gpu/drm/i915/intel_dp.c:1010:13: error: invalid storage class for function 'ironlake_wait_panel_off' drivers/gpu/drm/i915/intel_dp.c:1016:13: error: invalid storage class for function 'ironlake_wait_panel_power_cycle' drivers/gpu/drm/i915/intel_dp.c:1027:13: error: invalid storage class for function 'ironlake_get_pp_control' drivers/gpu/drm/i915/intel_dp.c:1075:13: error: invalid storage class for function 'ironlake_panel_vdd_off_sync' drivers/gpu/drm/i915/intel_dp.c:1097:13: error: invalid storage class for function 'ironlake_panel_vdd_work' drivers/gpu/drm/i915/intel_dp.c:1244:13: error: invalid storage class for function 'ironlake_edp_pll_on' drivers/gpu/drm/i915/intel_dp.c:1270:13: error: invalid storage class for function 'ironlake_edp_pll_off' drivers/gpu/drm/i915/intel_dp.c:1325:13: error: invalid storage class for function 'intel_dp_get_hw_state' drivers/gpu/drm/i915/intel_dp.c:1374:13: error: invalid storage class for function 'intel_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1390:13: error: invalid storage class for function 'intel_post_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1400:13: error: invalid storage class for function 'intel_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1419:13: error: invalid storage class for function 'intel_pre_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1432:1: error: invalid storage class for function 'intel_dp_aux_native_read_retry' drivers/gpu/drm/i915/intel_dp.c:1457:1: error: invalid storage class for function 'intel_dp_get_link_status' drivers/gpu/drm/i915/intel_dp.c:1483:1: error: invalid storage class for function 'intel_dp_voltage_max' drivers/gpu/drm/i915/intel_dp.c:14
Re: [git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com wrote: Hi, I am seeing this also on Linux-Next. /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! This seems to be hard reproducible... Laptop-LCD... Sandybridge Mobile-GT2. Is there a way to force the error? Possible patch see [1]. - Sedat - [1] https://patchwork.kernel.org/patch/2192721/ Hmm, I tried to apply the test-patch against next-20130227 and it fails building the i915 kernel-module. - Sedat - LD drivers/gpu/drm/i915/built-in.o CC [M] drivers/gpu/drm/i915/i915_drv.o CC [M] drivers/gpu/drm/i915/i915_dma.o CC [M] drivers/gpu/drm/i915/i915_irq.o CC [M] drivers/gpu/drm/i915/i915_debugfs.o CC [M] drivers/gpu/drm/i915/i915_suspend.o CC [M] drivers/gpu/drm/i915/i915_gem.o CC [M] drivers/gpu/drm/i915/i915_gem_context.o CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CC [M] drivers/gpu/drm/i915/i915_sysfs.o CC [M] drivers/gpu/drm/i915/i915_trace_points.o CC [M] drivers/gpu/drm/i915/i915_ums.o CC [M] drivers/gpu/drm/i915/intel_display.o CC [M] drivers/gpu/drm/i915/intel_crt.o CC [M] drivers/gpu/drm/i915/intel_lvds.o CC [M] drivers/gpu/drm/i915/intel_bios.o CC [M] drivers/gpu/drm/i915/intel_ddi.o CC [M] drivers/gpu/drm/i915/intel_dp.o drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_aux_wait_done': drivers/gpu/drm/i915/intel_dp.c:352:1: error: invalid storage class for function 'intel_dp_aux_ch' drivers/gpu/drm/i915/intel_dp.c:351:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/gpu/drm/i915/intel_dp.c:492:1: error: invalid storage class for function 'intel_dp_aux_native_write' drivers/gpu/drm/i915/intel_dp.c:525:1: error: invalid storage class for function 'intel_dp_aux_native_write_1' drivers/gpu/drm/i915/intel_dp.c:533:1: error: invalid storage class for function 'intel_dp_aux_native_read' drivers/gpu/drm/i915/intel_dp.c:572:1: error: invalid storage class for function 'intel_dp_i2c_aux_ch' drivers/gpu/drm/i915/intel_dp.c:669:1: error: invalid storage class for function 'intel_dp_i2c_init' drivers/gpu/drm/i915/intel_dp.c:845:13: error: invalid storage class for function 'ironlake_set_pll_edp' drivers/gpu/drm/i915/intel_dp.c:872:1: error: invalid storage class for function 'intel_dp_mode_set' drivers/gpu/drm/i915/intel_dp.c:985:13: error: invalid storage class for function 'ironlake_wait_panel_status' drivers/gpu/drm/i915/intel_dp.c:1004:13: error: invalid storage class for function 'ironlake_wait_panel_on' drivers/gpu/drm/i915/intel_dp.c:1010:13: error: invalid storage class for function 'ironlake_wait_panel_off' drivers/gpu/drm/i915/intel_dp.c:1016:13: error: invalid storage class for function 'ironlake_wait_panel_power_cycle' drivers/gpu/drm/i915/intel_dp.c:1027:13: error: invalid storage class for function 'ironlake_get_pp_control' drivers/gpu/drm/i915/intel_dp.c:1075:13: error: invalid storage class for function 'ironlake_panel_vdd_off_sync' drivers/gpu/drm/i915/intel_dp.c:1097:13: error: invalid storage class for function 'ironlake_panel_vdd_work' drivers/gpu/drm/i915/intel_dp.c:1244:13: error: invalid storage class for function 'ironlake_edp_pll_on' drivers/gpu/drm/i915/intel_dp.c:1270:13: error: invalid storage class for function 'ironlake_edp_pll_off' drivers/gpu/drm/i915/intel_dp.c:1325:13: error: invalid storage class for function 'intel_dp_get_hw_state' drivers/gpu/drm/i915/intel_dp.c:1374:13: error: invalid storage class for function 'intel_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1390:13: error: invalid storage class for function 'intel_post_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1400:13: error: invalid storage class for function 'intel_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1419:13: error: invalid storage class for function 'intel_pre_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1432:1: error: invalid storage class for function 'intel_dp_aux_native_read_retry' drivers/gpu/drm/i915/intel_dp.c:1457:1: error: invalid storage class for function 'intel_dp_get_link_status' drivers/gpu/drm/i915/intel_dp.c:1483:1: error: invalid storage class for function 'intel_dp_voltage_max' drivers/gpu/drm/i915/intel_dp.c:1496:1: error: invalid storage class for function 'intel_dp_pre_emphasis_max' drivers/gpu/drm/i915/intel_dp.c:1538:1: error
[git pull] drm merge for 3.9-rc1
Hi, I am seeing this also on Linux-Next. /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! This seems to be hard reproducible... Laptop-LCD... Sandybridge Mobile-GT2. Is there a way to force the error? Possible patch see [1]. - Sedat - [1] https://patchwork.kernel.org/patch/2192721/
gl.h: Version mumbo-jumbo and Copyright?
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote: > On 02/14/2013 01:10 PM, Sedat Dilek wrote: >> >> Hi, >> >> noticed when polishing up my build-scripts fot libdrm | mesa | >> xf86-video-intel (last one requires gl.h). >> >> /* >> * Mesa 3-D graphics library >> * Version: 7.6<--- ??? > > > I could remove that obsolete line. > > > >> * >> * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.<--- ??? >> * Copyright (C) 2009 VMware, Inc. All Rights Reserved. > > > What's the question there? > As we have 2013... - Sedat - > -Brian
gl.h: Version mumbo-jumbo and Copyright?
Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6 <--- ??? * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved. <--- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. ... Regards, - Sedat - http://cgit.freedesktop.org/mesa/mesa/tree/include/GL/gl.h#n3
gl.h: Version mumbo-jumbo and Copyright?
Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6 --- ??? * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved. --- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. ... Regards, - Sedat - http://cgit.freedesktop.org/mesa/mesa/tree/include/GL/gl.h#n3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gl.h: Version mumbo-jumbo and Copyright?
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul bri...@vmware.com wrote: On 02/14/2013 01:10 PM, Sedat Dilek wrote: Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6--- ??? I could remove that obsolete line. * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.--- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. What's the question there? As we have 2013... - Sedat - -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm-intel-nightly] drm/i915: Add a pipe A force quirk for Samsung NP530U3B-A01DE
IMPORTANT NOTE: *** This is just an experimental patch! ***
I fell over some "pipe A assertion" warnings while playing with
drm-intel-nightly
and contacted Daniel Vetter via PM.
[ dmesg ]
[ 19.948476] WARNING: at drivers/gpu/drm/i915/intel_display.c:1228
assert_pipe+0xde/0xe0 [i915]()
[ 19.948476] Hardware name: 530U3BI/530U4BI/530U4BH
[ 19.948477] pipe A assertion failure (expected on, current off)
Waiting for a reply, I looked into the code myself and found this snippet and
reflected about adding a quirk_pipea_force for my Intel SandyBridge GPU:
static struct intel_quirk intel_quirks[] = {
/* HP Mini needs pipe A force quirk (LP: #322104) */
{ 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
...
}
Unfortunately, it was not clear to me what each value of the triple means.
I started to investigate more in the logs:
[ Xorg.0.log ]
[16.421] (--) PCI:*(0:0:2:0) 8086:0116:144d:c0c7 rev 9, Mem
@0xf000/4194304, 0xe000/268435456, I/O @ 0x3000/64
This line gave me a 1st impression how my triple for a quirk line could look
like!
Finally, Jani Nikula gave me some helpful explanations in [1]:
>I guess you figured it out, but just a few lines up there's [1]:
struct intel_quirk {
int device;
int subsystem_vendor;
int subsystem_device;
void (*hook)(struct drm_device *dev);
};
>where device, subsystem_vendor, and subsystem_device map to Device,
>SVendor, and SDevice of the gfx controller in 'lspci -vmnn' output.
With these informations, I checked immediately here with 'lspci -vmnn' [2]:
Device: 00:02.0
Class: VGA compatible controller [0300]
Vendor: Intel Corporation [8086]
Device: 2nd Generation Core Processor Family Integrated Graphics Controller
[0116]
SVendor:Samsung Electronics Co Ltd [144d]
SDevice:Device [c0c7]
Rev:09
[ Triple revealed (w/o brackets) ]
Device (here: [0116]), SVendor (here: [144d]) and SDevice (here: [c0c7])
As a conclusion, I added the below QUIRK and it was successful:
[ dmesg ]
[ 15.047921] [drm] applying pipe a force quirk
Daniel removed the "buggy" patch which introduced the warning for non-HSW GPUs.
v3 in commit 693101618a4b [3] should be the revised patch.
[ References ]
[1] http://lists.freedesktop.org/archives/intel-gfx/2013-January/024160.html
[2] http://lists.freedesktop.org/archives/intel-gfx/2013-January/024161.html
[3]
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightly=693101618a4beedf1b3d291860aee56c5fe44a1c
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx
Cc: DRI
Signed-off-by: Sedat Dilek
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8c432a4..705fdb6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8607,6 +8607,9 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
};
static struct intel_quirk intel_quirks[] = {
+ /* Samsung NP530U3B-A01DE needs pipe A force quirk */
+ { 0x0116, 0x144d, 0xc0c7, quirk_pipea_force },
+
/* HP Mini needs pipe A force quirk (LP: #322104) */
{ 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
--
1.8.1.1
BUG: circular locking dependency detected
On Thu, Jan 31, 2013 at 11:12 AM, Sedat Dilek wrote: > [ CCing Linux-Next and MMOTM folks ] > > Original posting from Daniel see [0] > > [ QUOTE ] > On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman > wrote: >> On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote: >>> On Thu, Jan 31, 2013 at 11:13 AM, Russell King >>> wrote: >>> > >>> > Which may or may not be a good thing depending how you look at it; it >>> > means that once your kernel blanks, you get a lockdep dump. At that >>> > point you lose lockdep checking for everything else because lockdep >>> > disables itself after the first dump. >>> >>> Fair enough, we may want to revert the lockdep checking for >>> console_lock, and make re-enabling it part of the patch-series that >>> fixes the locking. >>> >>> Daniel/Dave? Does that sound reasonable? > > Yeah, sounds good. > >> Reverting the patch is fine with me. Just let me know so I can queue it >> up again for 3.9. > > Can you please also pick up the (currently) three locking fixups > around fbcon? Just so that we don't repeat the same fun where people > complain about lockdep splats, but the fixes are stuck somewhere. And > I guess Dave would be happy to not end up as fbcon maintainer ;-) He > has a git branch with them at > http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes > though I have a small bikeshed on his last patch pending. > -Daniel > [ /QUOTE ] > > Did the 3rd patch go also to mmotm tree and got marked for Linux-Next > inclusion? > Best would be to have it in mainline, finally. > Please, fix that for-3.8! > > Thanks to all volunteers (Alan, Andrew, Takashi Iwai (Sorry, dunno > which is 1st and last name), Daniel and finally Dave) trying to get > this incredible pain-in-the-a** upstream :-). > > - Sedat - > > [0] http://marc.info/?l=dri-devel=135962051326601=2 > [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes > [2] > http://cgit.freedesktop.org/~airlied/linux/commit/?h=fbcon-locking-fixes=98dfe36b5532576dedf41408d5bbd45fa31ec62d [ Adjusting outdated email-adresses, CC Borislav ] What's with the patch from [3] in mmotm? For-3.8, no more needed? - Sedat - [3] http://ozlabs.org/~akpm/mmots/broken-out/drm-fb-helper-dont-sleep-for-screen-unblank-when-an-oopps-is-in-progress.patch
BUG: circular locking dependency detected
[ CCing Linux-Next and MMOTM folks ] Original posting from Daniel see [0] [ QUOTE ] On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman wrote: > On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote: >> On Thu, Jan 31, 2013 at 11:13 AM, Russell King >> wrote: >> > >> > Which may or may not be a good thing depending how you look at it; it >> > means that once your kernel blanks, you get a lockdep dump. At that >> > point you lose lockdep checking for everything else because lockdep >> > disables itself after the first dump. >> >> Fair enough, we may want to revert the lockdep checking for >> console_lock, and make re-enabling it part of the patch-series that >> fixes the locking. >> >> Daniel/Dave? Does that sound reasonable? Yeah, sounds good. > Reverting the patch is fine with me. Just let me know so I can queue it > up again for 3.9. Can you please also pick up the (currently) three locking fixups around fbcon? Just so that we don't repeat the same fun where people complain about lockdep splats, but the fixes are stuck somewhere. And I guess Dave would be happy to not end up as fbcon maintainer ;-) He has a git branch with them at http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes though I have a small bikeshed on his last patch pending. -Daniel [ /QUOTE ] Did the 3rd patch go also to mmotm tree and got marked for Linux-Next inclusion? Best would be to have it in mainline, finally. Please, fix that for-3.8! Thanks to all volunteers (Alan, Andrew, Takashi Iwai (Sorry, dunno which is 1st and last name), Daniel and finally Dave) trying to get this incredible pain-in-the-a** upstream :-). - Sedat - [0] http://marc.info/?l=dri-devel=135962051326601=2 [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes [2] http://cgit.freedesktop.org/~airlied/linux/commit/?h=fbcon-locking-fixes=98dfe36b5532576dedf41408d5bbd45fa31ec62d
Re: BUG: circular locking dependency detected
[ CCing Linux-Next and MMOTM folks ] Original posting from Daniel see [0] [ QUOTE ] On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote: On Thu, Jan 31, 2013 at 11:13 AM, Russell King r...@arm.linux.org.uk wrote: Which may or may not be a good thing depending how you look at it; it means that once your kernel blanks, you get a lockdep dump. At that point you lose lockdep checking for everything else because lockdep disables itself after the first dump. Fair enough, we may want to revert the lockdep checking for console_lock, and make re-enabling it part of the patch-series that fixes the locking. Daniel/Dave? Does that sound reasonable? Yeah, sounds good. Reverting the patch is fine with me. Just let me know so I can queue it up again for 3.9. Can you please also pick up the (currently) three locking fixups around fbcon? Just so that we don't repeat the same fun where people complain about lockdep splats, but the fixes are stuck somewhere. And I guess Dave would be happy to not end up as fbcon maintainer ;-) He has a git branch with them at http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes though I have a small bikeshed on his last patch pending. -Daniel [ /QUOTE ] Did the 3rd patch go also to mmotm tree and got marked for Linux-Next inclusion? Best would be to have it in mainline, finally. Please, fix that for-3.8! Thanks to all volunteers (Alan, Andrew, Takashi Iwai (Sorry, dunno which is 1st and last name), Daniel and finally Dave) trying to get this incredible pain-in-the-a** upstream :-). - Sedat - [0] http://marc.info/?l=dri-develm=135962051326601w=2 [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes [2] http://cgit.freedesktop.org/~airlied/linux/commit/?h=fbcon-locking-fixesid=98dfe36b5532576dedf41408d5bbd45fa31ec62d ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: circular locking dependency detected
On Thu, Jan 31, 2013 at 11:12 AM, Sedat Dilek sedat.di...@gmail.com wrote: [ CCing Linux-Next and MMOTM folks ] Original posting from Daniel see [0] [ QUOTE ] On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote: On Thu, Jan 31, 2013 at 11:13 AM, Russell King r...@arm.linux.org.uk wrote: Which may or may not be a good thing depending how you look at it; it means that once your kernel blanks, you get a lockdep dump. At that point you lose lockdep checking for everything else because lockdep disables itself after the first dump. Fair enough, we may want to revert the lockdep checking for console_lock, and make re-enabling it part of the patch-series that fixes the locking. Daniel/Dave? Does that sound reasonable? Yeah, sounds good. Reverting the patch is fine with me. Just let me know so I can queue it up again for 3.9. Can you please also pick up the (currently) three locking fixups around fbcon? Just so that we don't repeat the same fun where people complain about lockdep splats, but the fixes are stuck somewhere. And I guess Dave would be happy to not end up as fbcon maintainer ;-) He has a git branch with them at http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes though I have a small bikeshed on his last patch pending. -Daniel [ /QUOTE ] Did the 3rd patch go also to mmotm tree and got marked for Linux-Next inclusion? Best would be to have it in mainline, finally. Please, fix that for-3.8! Thanks to all volunteers (Alan, Andrew, Takashi Iwai (Sorry, dunno which is 1st and last name), Daniel and finally Dave) trying to get this incredible pain-in-the-a** upstream :-). - Sedat - [0] http://marc.info/?l=dri-develm=135962051326601w=2 [1] http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes [2] http://cgit.freedesktop.org/~airlied/linux/commit/?h=fbcon-locking-fixesid=98dfe36b5532576dedf41408d5bbd45fa31ec62d [ Adjusting outdated email-adresses, CC Borislav ] What's with the patch from [3] in mmotm? For-3.8, no more needed? - Sedat - [3] http://ozlabs.org/~akpm/mmots/broken-out/drm-fb-helper-dont-sleep-for-screen-unblank-when-an-oopps-is-in-progress.patch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm-intel-nightly] drm/i915: Add a pipe A force quirk for Samsung NP530U3B-A01DE
IMPORTANT NOTE: *** This is just an experimental patch! ***
I fell over some pipe A assertion warnings while playing with
drm-intel-nightly
and contacted Daniel Vetter via PM.
[ dmesg ]
[ 19.948476] WARNING: at drivers/gpu/drm/i915/intel_display.c:1228
assert_pipe+0xde/0xe0 [i915]()
[ 19.948476] Hardware name: 530U3BI/530U4BI/530U4BH
[ 19.948477] pipe A assertion failure (expected on, current off)
Waiting for a reply, I looked into the code myself and found this snippet and
reflected about adding a quirk_pipea_force for my Intel SandyBridge GPU:
static struct intel_quirk intel_quirks[] = {
/* HP Mini needs pipe A force quirk (LP: #322104) */
{ 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
...
}
Unfortunately, it was not clear to me what each value of the triple means.
I started to investigate more in the logs:
[ Xorg.0.log ]
[16.421] (--) PCI:*(0:0:2:0) 8086:0116:144d:c0c7 rev 9, Mem
@0xf000/4194304, 0xe000/268435456, I/O @ 0x3000/64
This line gave me a 1st impression how my triple for a quirk line could look
like!
Finally, Jani Nikula gave me some helpful explanations in [1]:
I guess you figured it out, but just a few lines up there's [1]:
struct intel_quirk {
int device;
int subsystem_vendor;
int subsystem_device;
void (*hook)(struct drm_device *dev);
};
where device, subsystem_vendor, and subsystem_device map to Device,
SVendor, and SDevice of the gfx controller in 'lspci -vmnn' output.
With these informations, I checked immediately here with 'lspci -vmnn' [2]:
Device: 00:02.0
Class: VGA compatible controller [0300]
Vendor: Intel Corporation [8086]
Device: 2nd Generation Core Processor Family Integrated Graphics Controller
[0116]
SVendor:Samsung Electronics Co Ltd [144d]
SDevice:Device [c0c7]
Rev:09
[ Triple revealed (w/o brackets) ]
Device (here: [0116]), SVendor (here: [144d]) and SDevice (here: [c0c7])
As a conclusion, I added the below QUIRK and it was successful:
[ dmesg ]
[ 15.047921] [drm] applying pipe a force quirk
Daniel removed the buggy patch which introduced the warning for non-HSW GPUs.
v3 in commit 693101618a4b [3] should be the revised patch.
[ References ]
[1] http://lists.freedesktop.org/archives/intel-gfx/2013-January/024160.html
[2] http://lists.freedesktop.org/archives/intel-gfx/2013-January/024161.html
[3]
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightlyid=693101618a4beedf1b3d291860aee56c5fe44a1c
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jani Nikula jani.nik...@linux.intel.com
Cc: intel-gfx intel-...@lists.freedesktop.org
Cc: DRI dri-devel@lists.freedesktop.org
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8c432a4..705fdb6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8607,6 +8607,9 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
};
static struct intel_quirk intel_quirks[] = {
+ /* Samsung NP530U3B-A01DE needs pipe A force quirk */
+ { 0x0116, 0x144d, 0xc0c7, quirk_pipea_force },
+
/* HP Mini needs pipe A force quirk (LP: #322104) */
{ 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
--
1.8.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] Adding a i915 quirk (here: pipe A force quirk for testing purposes)?
On Mon, Jan 28, 2013 at 4:01 PM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Mon, 28 Jan 2013, Sedat Dilek sedat.di...@gmail.com wrote:
...
static struct intel_quirk intel_quirks[] = {
/* HP Mini needs pipe A force quirk (LP: #322104) */
{ 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
...
}
Triple - which value is what?
I guess you figured it out, but just a few lines up there's [1]:
struct intel_quirk {
int device;
int subsystem_vendor;
int subsystem_device;
void (*hook)(struct drm_device *dev);
};
where device, subsystem_vendor, and subsystem_device map to Device,
SVendor, and SDevice of the gfx controller in 'lspci -vmnn' output.
Oh, cool.
Did not know of these parameters...
Device: 00:02.0
Class: VGA compatible controller [0300]
Vendor: Intel Corporation [8086]
Device: 2nd Generation Core Processor Family Integrated Graphics
Controller [0116]
SVendor:Samsung Electronics Co Ltd [144d]
SDevice:Device [c0c7]
Rev:09
...together with the pasted code-snippet, it is clear to me!
Thanks for the explanation and hints!
- Sedat -
HTH,
Jani.
[1]
http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915/intel_display.c?h=drm-intel-nightly#n8574
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
