Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Souza, Jose schreef op vr 09-08-2019 om 17:16 [+]: > Fix released on Linux 5.2.8 Linux 5.2.8 doesn't have the pretty obvious freezes so this fix works for me too. Thanks for letting me know! Paul Bolle
Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Hi Jose,
Souza, Jose schreef op wo 24-07-2019 om 20:27 [+]:
> We fixed the patch instead of revert it, it is merged on drm-tip and on
> his way to linux-stable.
That should be (drm-tip) commit b5ea9c933700 ("drm/i915/vbt: Fix VBT parsing
for the PSR section"). Correct?
> Huge thanks again
You're welcome.
Paul Bolle
Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Hi Jose, James Bottomley schreef op do 18-07-2019 om 06:29 [+0900]: > On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote: > > I've just reached a day of uptime with your revert. (The proper > > uptime is just a fraction of a day, this being a laptop.) Anyhow, no > > screen freezes occurred during this day. > > I'm afraid my status is that I'm in Tokyo doing conference > presentations (and kernel demos) so I'm a bit reluctant to mess with my > setup until I finish everything on Friday, but I will test it after > then, promise. By now I'm testing this for a week (currently on top of 5.2.2). Still no freezes whatsoever. So what's the status of this revert? Unless this is something pretty obscure that for some odd reason only James and I are able to hit it would be nice to get this into stable before the main distros switch over to 5.2.y. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Hi Jose, Souza, Jose schreef op di 16-07-2019 om 16:32 [+]: > Paul and James could you test this final solution(at least for 5.2)? > Please revert the hack patch and apply this one. I've just reached a day of uptime with your revert. (The proper uptime is just a fraction of a day, this being a laptop.) Anyhow, no screen freezes occurred during this day. So feel free to add my Tested-by tag to your revert. But please don't forget that James earned a Reported-by tag. Thanks, Paul Bolle
Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Hi Jose, Souza, Jose schreef op ma 15-07-2019 om 21:03 [+]: > So the issue did not happened again with the patch applied? Not in the three days that I've been running 5.2 kernels with the hack applied (so that should be about twelve hours of proper uptime). > If you still have the kernel 5.1 installed could you share your > /sys/kernel/debug/dri/0/i915_edp_psr_status with the older kernel? > We want to check if training values changed between kernel versions. Sure. On 5.1.17 I get: Sink support: yes [0x01] PSR mode: PSR1 enabled Source PSR ctl: enabled [0x81f00626] Source PSR status: IDLE [0x040b0001] Busy frontbuffer bits: 0x And, in case you need it, on 5.2.1+hack I get: Sink support: yes [0x01] PSR mode: PSR1 enabled Source PSR ctl: enabled [0x81f00626] Source PSR status: IDLE [0x04030006] Busy frontbuffer bits: 0x Hope this helps, Paul
Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
James Bottomley schreef op vr 12-07-2019 om 07:19 [-0700]: > It has survived 6h without manifesting the regression. Starting again > to try a whole day. And I'm currently at four hours without a screen freeze. Which is much, much longer than I was able to achieve without the hack applied. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Paul Bolle schreef op do 11-07-2019 om 13:20 [+0200]: > Chris Wilson schreef op do 11-07-2019 om 10:29 [+0100]: > > Temporary workaround would be to set i915.enable_psr=0 > > That workaround seems to work for me. Over an hour of uptime without any > screen freezes. May or may not be related: 24 hours into that session I had the machine lock up hard. Screen frozen, no input possible, etc. I had to power cycle it (after half an hour, behaving very patient). But the screen freeze that we're focusing on here never occurred during this session. Paul Bolle
Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]: > On Thu, 2019-07-11 at 22:26 +, Souza, Jose wrote: > > It eventually comes back from screen freeze? Like moving the mouse or > > typing brings it back? > > No, it seems to be frozen for all time (at least until I got bored > waiting, which was probably 20 minutes). Even if I reboot the machine, > the current screen state stays until the system powers off. As I mentioned earlier, a suspend/resume cycle unfreezes the screen. And I seem to remember that, if the gnome screen-locking eventually kicks in, unlocking the screen still works, as the screen then isn't frozen anymore. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Chris Wilson schreef op do 11-07-2019 om 10:29 [+0100]: > Temporary workaround would be to set i915.enable_psr=0 That workaround seems to work for me. Over an hour of uptime without any screen freezes. (I first tried fiddling with /sys/module/i915/parameters/enable_psr at runtime, but that apparently has no effect. Should that file be read-only?) Feel free to ask me to test a fix (or a revert) once you've figured out what to do about this. Paul Bolle
Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
James Bottomley schreef op wo 10-07-2019 om 10:35 [-0700]: > I can get back to it this afternoon, when I'm done with the meeting > requirements and doing other dev stuff. I've started bisecting using your suggestion of that drm merge: $ git bisect log git bisect start # good: [89c3b37af87ec183b666d83428cb28cc421671a6] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide git bisect good 89c3b37af87ec183b666d83428cb28cc421671a6 # bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c # bad: [ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217] drm/i915: Update DRIVER_DATE to 20190417 git bisect bad ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217 Git told me I have nine steps after this. So at two hours per step I might pinpoint the offending commit by Friday the 12th. If I'm lucky. (There are other things to do than bisecting this issue.) If you find that commit before I do, I'll be all ears. Thanks, Paul Bolle
Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
James Bottomley schreef op wo 10-07-2019 om 09:32 [-0700]: > You seem to be getting it to happen much more often than I can. Last > night, on the below pull request it took me a good hour to see the > freeze. Yes. Sometimes within a minute of resuming. Typing stuff into evolution seems to help with triggering this. It's all a bit mysterious, but this message alone frooze my laptop a few times. Seriously! > Sure, my current testing indicates it's somewhere inside this pull > request: > > Merge: 89c3b37af87e eb85d03e01c3 > Author: Linus Torvalds > Date: Wed May 8 21:35:19 2019 -0700 > > Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm > > Pull drm updates from Dave Airlie: Lazy question: how does one determine the first and last commit inside a merge request? Can I simply do good a2d635decbfa9c1e4ae15cb05b68b2559f7f827c^ bada2d635decbfa9c1e4ae15cb05b68b2559f7f827c for git bisect? > So I was about to test out the i915 changes in that but since my laptop > is what I use for daily work, it's a bit hard (can't freeze up on video > calls for instance). I usually use one of the ThinkPads from my embarrassing pile of outdated hardware to do nasty bisects, but I'm not about to loose any income if my much appreciated XPS 13 is out of order for a while. Thanks, Paul Bolle
Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Hi James, James Bottomley schreef op wo 10-07-2019 om 08:01 [-0700]: > I've confirmed that 5.1 doesn't have the regression and I'm now trying > to bisect the 5.2 merge window, but since the problem takes quite a > while to manifest this will take some time. Any hints about specific > patches that might be the problem would be welcome. (Perhaps my message of yesterday never reached you.) It seems I hit this problem quite easily. Bisecting v5.1..v5.2 could be a real chore, so perhaps we could coordinate efforts (off-list)? Thanks, Paul Bolle
Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915
Hi James, James Bottomley schreef op za 29-06-2019 om 11:56 [-0700]: > The symptoms are really weird: the screen image is locked in place. > The machine is still functional and if I log in over the network I can > do anything I like, including killing the X server and the display will > never alter. It also seems that the system is accepting keyboard input > because when it freezes I can cat information to a file (if the mouse > was over an xterm) and verify over the network the file contents. > Nothing unusual appears in dmesg when the lockup happens. > > The last kernel I booted successfully on the system was 5.0, so I'll > try compiling 5.1 to narrow down the changes. Upgrading to 5.2 (from 5.1.y) on a "Dell XPS 13 9350" (is that a skylake too?) showed similar symptoms. There's no pattern to the freezes that I can see. They're rather frequent too (think every few minutes). Eg, two freezes while composing this message! My totally silly workaround is suspending (via Fn + Insert) and resuming. Did you manage to narrow this any further? Thanks, Paul Bolle
Re: [Intel-gfx] [PATCH v6 05/99] xarray: Add definition of struct xarray
Mathhew, Just a minor question. On Wed, 2018-01-17 at 12:20 -0800, Matthew Wilcox wrote: > This is a direct replacement for struct radix_tree_root. Some of the > struct members have changed name; convert those, and use a #define so > that radix_tree users continue to work without change. > > Signed-off-by: Matthew Wilcox > --- a/include/linux/xarray.h > +++ b/include/linux/xarray.h > @@ -10,6 +10,8 @@ > */ > > #include > +#include > +#include The top Makefile includes linux/kconfig.h globally. (See the odd USERINCLUDE variable, which is actually part of the LINUXINCLUDE variable, but split off to make things confusing.) Why do you need to include linux/kconfig.h here? > #include > #include Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
On Mon, 2016-11-14 at 18:35 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When we end up not recomputing the cdclk, we need to populate
> intel_state->cdclk with the "atomic_cdclk_freq" instead of the
> current cdclk_freq. When no pipes are active, the actual cdclk_freq
> may be lower than what the configuration of the planes and
> pipes would require from the point of view of the software state.
>
> This fixes bogus WARNS from skl_max_scale() which is trying to check
> the plane software state against the cdclk frequency. So any time
> it got called during DPMS off for instance, we might have tripped
> the warn if the current mode would have required a higher than
> minimum cdclk.
>
> v2: Drop the dev_cdclk stuff (Maarten)
>
> Cc: Maarten Lankhorst
> Cc: Mika Kahola
> Cc: bruno.pag...@ens-lyon.org
> Cc: Daniel J Blueman
> Cc: Paul Bolle
> Cc: Joseph Yasi
> Tested-by: Paul Bolle (v1)
I've run v2 of this patch (on top of v4.8.8) for over a day now without
hitting the WARN_ON_ONCE. Of course, my machine was suspended for large parts
of that period. But still, the WARN_ON_ONCE used to be triggered much quicker.
So in short: you can drop "(v1)" as I tested both versions now.
By the way, the scary i915 *ERROR*s are gone now too, as are the visual
glitches that accompanied those *ERROR*s. Apparently the v4.8.y series picked
up a few fixes. Those made i915 a much better experience. Nice!
> Tested-by: Joseph Yasi (v1)
> Cc: sta...@vger.kernel.org
> Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were
> active.")
(I seem to remember discussing the reasons why a v4.6 bug was first noticed on
v4.8. I haven't looked into that yet. By now it's unlikely I ever will. Sorry
about that.)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Maarten Lankhorst
Thanks,
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections
On Thu, 2016-11-03 at 02:16 -0700, Joe Perches wrote: > Yes, it's been reported and should be fixed in -mm. > The fix should show up in -next in a little bit. Great. > For now, try: > $ sed -i -e 's/\xA0/ /g' scripts/get_maintainer.pl Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections
On Mon, 2016-10-24 at 11:05 -0700, Joe Perches wrote:
> Jani Nikula proposes patches to add a few new letter prefixes
> for "B:" bug reporting and "C:" maintainer chatting to the
> various sections of MAINTAINERS.
>
> Add a generic mechanism to get_maintainer.pl to find sections that
> have any combination of "[A-Z]" letter prefix types in a section.
>
> Signed-off-by: Joe Perches
This patch made it into linux-next (ie, next-20161028).
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -271,7 +273,8 @@ $output_multiline = 0 if ($output_separator ne ", ");
> $output_rolestats = 1 if ($interactive);
> $output_roles = 1 if ($output_rolestats);
>
> -if ($sections) {
> +if ($sections || $letters ne "") {
> +$sections = 1;
This triggers:
Unrecognized character \xA0; marked by <-- HERE after <-- HERE near column
1 at ./scripts/get_maintainer.pl line 277.
Git blame shows:
git blame -L 277,+1 ./scripts/get_maintainer.pl
b67071653d3fc (Joe Perches 2016-10-28 13:22:01 +1100 277)
$sections = 1;
(A0 seems to be the no break space. That character was inserted more
often further down the patch.)
Anybody else seeing this?
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
On Tue, 2016-11-01 at 09:57 +0100, Maarten Lankhorst wrote: > Otherwise looks sane, I have a similar patch in my tree. I didn't > submit it yet but the fix was similar. Except for the > dev_cdclk stuff. > > With the last dev_cdclk assignment removed: > > Reviewed-by: Maarten Lankhorst So I've been running this patch for a few days now. First I tested it on top of v4.8.4. Now I'm running it on top of v4.8.5. My current v4.8.5 boot saw this new (for me) *ERROR*, twice: <3>[43483.521341] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU about cdclk change <3>[108639.090776] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU about cdclk change Related or a coincidence? Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
On Sat, 2016-10-29 at 00:30 +0300, Ville Syrjälä wrote:
> I think it was probably due to
>
> commit 44d1240d006c9cd0249263b5449c8e4752500f6a
> Author: Marek Szyprowski
> Date: Mon Jun 13 11:11:26 2016 +0200
>
> drm: add generic zpos property
>
> If you want want to grade my answer all you have to do is revert that
> on 4.8 and see what happens. Might be interesting to see if I'm right
> actually since the link between the WARN and that commit isn't entirely
> obvious.
You mean reverting commit 44d1240d006c ("drm: add generic zpos
property") and not applying this fix, right?
Anyway, I'm happy to grade your answer in a few days. Please prod if
notifying you of your grade takes too long.
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
On Fri, 2016-10-28 at 19:59 +0300, ville.syrj...@linux.intel.com wrote:
> Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were
> active.")
Obviously, I'm pretty happy with this patch. One question though: this
fixes a commit that shipped in v4.6. Do you have any idea why this
issue apparently never surfaced before v4.8?
Thanks,
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[Detailed post, but please give it a quick scan.]
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> > start.
>
> That would be between v4.7 and v4.8. (I guess my report was
> ambiguous.)
>
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
0) So I've lost my courage to do a bisect when my first attempt landed
me in v4.6-rc3. This is about for issue popping up between v4.7 and
v4.8-rc1.
1) So I used the most reliable debugging tool that I actually
understand: printk():
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fbcfed63a76e..791de414cf1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct
intel_crtc_state *crtc_state
return DRM_PLANE_HELPER_NO_SCALING;
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
- cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(!crtc_clock))
+ return DRM_PLANE_HELPER_NO_SCALING;
- if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
+ cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(cdclk < crtc_clock)) {
+ printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk,
crtc_clock);
return DRM_PLANE_HELPER_NO_SCALING;
+ }
+
+ printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n",
cdclk, crtc_clock);
/*
* skl max scale is lower of:
2) This taught me that crtc_clock always is 373250 on my machine. cdclk
mostly is 45, but every now and then it briefly is 337500.
3) Now the interesting pattern is that cdclk drops to 337500 only after
two quick calls of skl_max_scale() with cdclk set to 45, and a
roughly 300ms pause before the third call of that function. Example:
<7>[23758.501933] i915: cdclk >= crtc_clock: 45 >= 373250
<7>[23758.515211] i915: cdclk >= crtc_clock: 45 >= 373250
<7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
This pattern of cdclk being 337500 after roughly 300ms is surprisingly
stable.
4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
that sets cdclk to 337500 and triggers this issue. Ideas?
To be continued,
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[Adding Matt]
On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> start.
0) Why use a personal notebook when one can just post any half baked
idea to lkml?
1) I stumbled on https://bugzilla.redhat.com/show_bug.cgi?id=1361357 (s
ame hardware, rather similar trace).
2) That report was about the first Fedora (rawhide) kernel release
after this commit http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/co
mmit/?h=f25&id=7d2c2f2d91793b5da452bee9bea4fa32051c8608 ("Bring in
patch-series from drm-next to fix skl_update_other_pipe_wm issues").
3) That seventeen part series ended up in v4.8. The last commit of that
series is commit 5b483747a925 ("drm/i915: Remove wm_config from
dev_priv/intel_atomic_state").
4) So, with a little bit of luck, my bisect might only need to look at
those seventeen commits. Still, it will probably be next week before I
have a day or two to actually perform that bisect.
To be continued,
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote: > That might take some time. Because bisecting always takes a long time > and especially since hitting this WARNING sometimes takes over an hour. > Anyhow, please prod me if I stay silent for too long. For the record: I just had to power cycle this laptop because it got into that lovely state where it just locks without accepting any input (no, I don't have netconsole enabled). Assuming this lockup is related: this could be more urgent than I thought. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On Wed, 2016-10-12 at 17:34 +0300, Jani Nikula wrote: > In the mean time, please file a bug over at [1] so we don't lose > track. Done: https://bugs.freedesktop.org/show_bug.cgi?id=98214 Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: > Bisecting the offending commit between v4.8 and v4.8.1 would be a good > start. That would be between v4.7 and v4.8. (I guess my report was ambiguous.) That might take some time. Because bisecting always takes a long time and especially since hitting this WARNING sometimes takes over an hour. Anyhow, please prod me if I stay silent for too long. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On a laptop that tracks the latest stable release (Ie, it now runs v4.8.1) I see this WARNING WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Full trace pasted below. I never saw this WARNING before v4.8. Since v4.8 I've had it in all (four, actually) boots. What am I expected to do about this WARNING? Thanks, Paul Bolle WARNING: CPU: 3 PID: 1368 at drivers/gpu/drm/i915/intel_display.c:14178 skl_max_scale.part.120+0x75/0x80 [i915] WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Modules linked in: rfcomm fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 cmac nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables bnep vfat fat arc4 snd_hda_codec_hdmi snd_soc_skl dell_led snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match snd_soc_core intel_rapl snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal coretemp kvm_intel snd_compress snd_pcm_dmaengine ac97_bus kvm snd_hda_intel iwlmvm snd_hda_codec mac80211 iTCO_wdt iTCO_vendor_support uvcvideo snd_hda_core snd_hwdep snd_seq irqbypass dell_laptop i2c_designware_platform i2c_designware_core dell_wmi crct10dif_pclmul dell_smbios dcdbas crc32_pclmul snd_seq_device iwlwifi videobuf2_vmalloc videobuf2_memops ghash_clmulni_intel snd_pcm videobuf2_v4l2 videobuf2_core cfg80211 videodev media joydev pcspkr mei_me rtsx_pci_ms memstick snd_timer i2c_i801 i2c_smbus mei snd btusb soundcore shpchp hci_uart btrtl btbcm btqca idma64 btintel bluetooth intel_pch_thermal processor_thermal_device intel_lpss_pci intel_soc_dts_iosf wmi pinctrl_sunrisepoint intel_lpss_acpi rfkill pinctrl_intel intel_lpss int3400_thermal acpi_als int3403_thermal int340x_thermal_zone kfifo_buf acpi_thermal_rel intel_hid industrialio sparse_keymap acpi_pad tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc hid_multitouch i915 rtsx_pci_sdmmc mmc_core i2c_algo_bit drm_kms_helper crc32c_intel drm serio_raw nvme rtsx_pci nvme_core i2c_hid video fjes CPU: 3 PID: 1368 Comm: Xorg Not tainted 4.8.1-1.local1.fc24.x86_64 #1 Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.4.4 06/14/2016 0286 df2f374c a31528d53910 b83e5cfd a31528d53960 a31528d53950 b80a7d5b 3762c72b3010 a3151e4d8cc0 a31526c23800 a31526e6 Call Trace: [] dump_stack+0x63/0x86 [] __warn+0xcb/0xf0 [] warn_slowpath_fmt+0x5f/0x80 [] ? sort+0x147/0x220 [] ? drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper] [] skl_max_scale.part.120+0x75/0x80 [i915] [] intel_check_primary_plane+0xc6/0xe0 [i915] [] ? drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper] [] intel_plane_atomic_check+0x132/0x1f0 [i915] [] drm_atomic_helper_check_planes+0x84/0x200 [drm_kms_helper] [] intel_atomic_check+0x9a7/0x11a0 [i915] [] ? __kmalloc_track_caller+0x17a/0x210 [] drm_atomic_check_only+0x187/0x610 [drm] [] ? drm_atomic_get_crtc_state+0x88/0x100 [drm] [] drm_atomic_commit+0x17/0x60 [drm] [] drm_atomic_helper_update_plane+0xec/0x130 [drm_kms_helper] [] __setplane_internal+0x22b/0x270 [drm] [] drm_mode_cursor_universal+0x139/0x240 [drm] [] drm_mode_cursor_common+0x7e/0x180 [drm] [] drm_mode_cursor2_ioctl+0xe/0x10 [drm] [] drm_ioctl+0x1da/0x4b0 [drm] [] ? drm_mode_cursor_ioctl+0x70/0x70 [drm] [] ? enqueue_hrtimer+0x3d/0x80 [] do_vfs_ioctl+0xa3/0x5e0 [] ? __sys_recvmsg+0x51/0x90 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver
[Added Paul Gortmaker.] Hi Shobhit, On Fri, 2015-06-19 at 12:16 +0530, Shobhit Kumar wrote: > So what is the exact big problem with this ? The main problem I have is that it's hard to read a submitter's mind. And, I think, in cases like this we need to know if the submitter just made some silly mistake or that the mismatch (between Kconfig type and code) was intentional. So each time such a mismatch is spotted the submitter ought to be asked about it. (I'd guess that one or two new drivers are submitted _each_ day. And these mismatches are quite common. I'd say I receive answers like: - "Oops, yes bool should have been tristate"; or - "Oops, forgot to clean up after noticing tristate didn't work"; or - "I just copy-and-pasted a similar driver, the module stuff isn't actually needed" at least once a week. Not sure, I don't keep track of this stuff.) Furthermore, it appears that Paul Gortmaker is on a mission to, badly summarized, untangle the module and init code. See for instance https://lkml.org/lkml/2015/5/28/809 and https://lkml.org/lkml/2015/5/31/205 . Now, I don't know whether (other) Paul is bothered by these MODULE_* macros. But Paul did submit a series that adds builtin_platform_driver(), see https://lkml.org/lkml/2015/5/10/131 . That new macro ensures built-in only code doesn't have to use module_platform_driver(), which your patch also uses. So perhaps Paul can explain some of the non-obvious issues caused by built-in only code using module specific constructs. > I can anyway shove out these macros to end the discussion. I'd rather convince you than annoy you into doing as I suggested. > BTW whether you buy the argument or not, please do treat yourself > with ice cream for being able to make such a comment. Will do. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too
On Fri, 2015-06-19 at 17:44 +0200, Daniel Vetter wrote: > I wonder whether we shouldn't do this unconditionally for gen4 and earlier > for Lenovo ... Anyway this needs Cc: sta...@vger.kernel.org and is for > Jani to pick up. > > Thanks for figuring out what's been broken here. > -Daniel > > > pci_set_power_state(drm_dev->pdev, PCI_D3hot); > > > > return 0; Just two days ago we discussed this bug too, see https://lkml.org/lkml/2015/6/17/327 . That message contains a link to a patch I cobbled together for yet another ThinkPad hitting this, but with PCI_SUBVENDOR_ID_IBM involved. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver
Hi Shobhit, On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote: > On Fri, May 1, 2015 at 2:42 AM, Paul Bolle wrote: > > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote: > >> --- a/drivers/pwm/Kconfig > >> +++ b/drivers/pwm/Kconfig > > > >> +config PWM_CRC > >> + bool "Intel Crystalcove (CRC) PWM support" > >> + depends on X86 && INTEL_SOC_PMIC > >> + help > >> + Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM > >> + control. > > > >> --- a/drivers/pwm/Makefile > >> +++ b/drivers/pwm/Makefile > > > >> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o > > > > PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module. > > I actually started this as a module but later decided to make it as > bool because INTEL_SOC_PMIC on which this depends is itself a bool as > well. As does GPIO_CRYSTAL_COVE and that's a tristate. So? > Still it is good to keep the module based initialization. > Firstly because it causes no harm If I got a dime for every time people used an argument like that I ... I could treat myself to an ice cream. A really big ice cream. Hmm, that doesn't sound too impressive. But still, "causes no harm" is below the bar for kernel code. Kernel code needs to add value. > and even though some of the macros > are pre-processed out, gives info about the driver. None of which can't be gotten elsewhere (ie, the commit message, or the file these macro reside in). > Secondly there > were discussion on why INTEL_SOC_PMIC is bool (note this driver also > has module based initialization even when bool). Yes, there's copy and paste going on even in kernel development. > I am guessing because > of some tricky module load order dependencies. If ever that becomes a > module, this can mostly be unchanged to be loaded as a module. You put in a macro, or any other bit of code, when it's needed, not beforehand, "just in case". That's silly. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] pwm: crc: Add Crystalcove (CRC) PWM driver
On Tue, 2015-05-05 at 15:08 +0530, Shobhit Kumar wrote: > The Crystalcove PMIC controls PWM signals and this driver exports that > capability as a PWM chip driver. This is platform device implementtaion > of the drivers/mfd cell device for CRC PMIC > > v2: Use the existing config callback with duty_ns and period_ns(Thierry) > > v3: Correct the subject line (Lee jones) > > CC: Samuel Ortiz > Cc: Linus Walleij > Cc: Alexandre Courbot > Cc: Thierry Reding > Signed-off-by: Shobhit Kumar The same comments can be made as for v2, see http://lkml.kernel.org/r/1430428322.2187.24.camel@x220 . Maybe you didn't receive that message. It could also be that you think my comments were invalid, or too vague, or whatever. Please say so, because then I don't have to bother you again when you send out v4. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver
On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> +config PWM_CRC
> + bool "Intel Crystalcove (CRC) PWM support"
> + depends on X86 && INTEL_SOC_PMIC
> + help
> + Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
> + control.
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module.
(If I'm wrong, and that object file can actually be part of a module,
you can stop reading here.)
> --- /dev/null
> +++ b/drivers/pwm/pwm-crc.c
> +#include
Perhaps this include is not needed.
> +static const struct pwm_ops crc_pwm_ops = {
> + .config = crc_pwm_config,
> + .enable = crc_pwm_enable,
> + .disable = crc_pwm_disable,
> + .owner = THIS_MODULE,
For built-in only code THIS_MODULE is basically equivalent to NULL (see
include/linux/export.h). So I guess this line can be dropped.
> +};
> +static struct platform_driver crystalcove_pwm_driver = {
> + .probe = crystalcove_pwm_probe,
> + .remove = crystalcove_pwm_remove,
> + .driver = {
> + .name = "crystal_cove_pwm",
> + },
> +};
> +
> +module_platform_driver(crystalcove_pwm_driver);
Speaking from memory: for built-in only code this is equivalent to
calling
platform_driver_register(&crystalcove_pwm_driver);
from a wrapper, and marking that wrapper with device_initcall().
> +MODULE_AUTHOR("Shobhit Kumar ");
> +MODULE_DESCRIPTION("Intel Crystal Cove PWM Driver");
> +MODULE_LICENSE("GPL v2");
These macros will be effectively preprocessed away for built-in only
code.
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: gen4: work around hang during hibernation
On Wed, 2015-03-18 at 12:22 +0200, Ville Syrjälä wrote: > We had another bug report which showed similar problems on something > as recent as SNB: > https://bugzilla.kernel.org/show_bug.cgi?id=94241 > So I guess we really want to make the check 'gen < 7'. > > My IVB X1 Carbon doesn't need this quirk, so hopefully that indicates > the Lenovo BIOSen became more sane for gen7+. On the other hand my ThinkPad X220 has vendor:device ids 8086:0126, which makes it a gen6 device (assuming I parsed the various preprocessor defines in include/drm/i915_pciids.h and drivers/gpu/drm/i915/i915_drv.c correctly). That laptop is now running v3.19.1 and never hit this issue. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: gen4: work around hang during hibernation
Imre Deak schreef op ma 02-03-2015 om 13:04 [+0200]:
> Bjørn reported that his machine hang during hibernation and eventually
> bisected the problem to the following commit:
>
> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> Author: Imre Deak
> Date: Thu Oct 23 19:23:26 2014 +0300
>
> drm/i915: add poweroff_late handler
>
> The problem seems to be that after the kernel puts the device into D3
> the BIOS still tries to access it, or otherwise assumes that it's in D0.
> This is clearly bogus, since ACPI mandates that devices are put into D3
> by the OSPM if they are not wake-up sources. In the future we want to
> unify more of the driver's runtime and system suspend paths, for example
> by skipping all the system suspend/hibernation hooks if the device is
> runtime suspended already. Accordingly for all other platforms the goal
> is still to properly power down the device during hibernation.
>
> v2:
> - Another GEN4 Lenovo laptop had the same issue, while platforms from
> other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
> to work fine. Based on this apply the workaround on all GEN4 Lenovo
> platforms.
> - add code comment about failing platforms (Ville)
The outdated ThinkPad X41 that I torture by running rc's showed
identical symptoms, also since v3.19-rc1. It uses a gen3 chipset (it has
a 915GM, I think, but I keep forgetting details like that).
I did everything wrong to get this fixed (1: hope this gets magically
fixed; 2: bisect it myself, thinking every now and then that I know
better than git bisect which commit to choose; 3: finally grep lkml). So
here I am late to the show.
> Reference:
> http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
> Reported-and-bisected-by: Bjørn Mork
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.c | 30 +-
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4badb23..ff3662f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -637,7 +637,7 @@ static int i915_drm_suspend(struct drm_device *dev)
> return 0;
> }
>
> -static int i915_drm_suspend_late(struct drm_device *drm_dev)
> +static int i915_drm_suspend_late(struct drm_device *drm_dev, bool
> hibernation)
> {
> struct drm_i915_private *dev_priv = drm_dev->dev_private;
> int ret;
> @@ -651,7 +651,17 @@ static int i915_drm_suspend_late(struct drm_device
> *drm_dev)
> }
>
> pci_disable_device(drm_dev->pdev);
> - pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> + /*
> + * During hibernation on some GEN4 platforms the BIOS may try to access
> + * the device even though it's already in D3 and hang the machine. So
> + * leave the device in D0 on those platforms and hope the BIOS will
> + * power down the device properly. Platforms where this was seen:
> + * Lenovo Thinkpad X301, X61s
> + */
> + if (!(hibernation &&
> + drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
> + INTEL_INFO(dev_priv)->gen == 4))
> + pci_set_power_state(drm_dev->pdev, PCI_D3hot);
>
> return 0;
> }
I'll paste a DRAFT patch that fixes this for that X41 at the end of the
message. The patch is rather ugly. Should we perhaps try a quirk table
or something like that?
Paul Bolle
>8
Subject: [PATCH] drm/i915: work around hang during hibernation on gen3 too
Commit ab3be73fa7b4 ("drm/i915: gen4: work around hang during
hibernation") was targetted at gen4 platforms shipped by Lenovo. The
same problem can also be seen on a Lenovo ThinkPad X41. Expand the test
to catch that system too.
Sadly, this system still uses IBM's subsystem vendor id. So we end up
with a rather unpleasant test. Use the IS_GEN3() and IS_GEN4() macros to
lessen the pain a bit.
Not-yet-signed-off-by: Paul Bolle
---
drivers/gpu/drm/i915/i915_drv.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc6ea53d2b81..3a07164f5860 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -641,11 +641,12 @@ static int i915_drm_suspend_late(struct drm_device
*drm_dev, bool hibernation)
* the device even though it's already in D3 and hang the machine. So
* leave the device in D0 on those platforms and hope the BIOS will
* power down the device properly. Platforms where this was seen:
-* Lenovo Thinkpad X301, X61s
+* Lenovo Thinkpad X301, X61s, X41
*/
if
Re: [Intel-gfx] [git pull] drm fixes
On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
> Hmm. 3.19 works fine, even if it ends up spewing
>
> WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
> drm_wait_one_vblank+0x125/0x130()
> vblank not available on crtc 1, ret=-22
>
> a lot.
For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
in http://lkml.kernel.org/r/20150131211609.GA3710@yulia-desktop .
Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
commit will end up in v3.19-stable in due time.
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove references to previously removed UMS config option
On Fri, 2015-02-06 at 11:16 +0100, Andreas Ruprecht wrote:
> Commit 03dae59c72d8 ("drm/i915: Ditch UMS config option") removed
> CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still
> references this option in two #ifndef statements.
>
> As an undefined config option will always be 'false', we can drop
> the #ifndefs alltogether and adapt the printed error message.
>
> This inconsistency was found with the undertaker tool.
>
> Signed-off-by: Andreas Ruprecht
> ---
Previously discussed in
http://lists.freedesktop.org/archives/dri-devel/2014-July/064702.html
(but not on lkml). If I understand Daniels message correctly this
$ git grep -n '!drm_core_check_feature' | grep -w DRIVER_MODESET | wc -l
43
means the cleanup needed to be done before this cleanup will be applied,
hasn't happened yet.
> drivers/gpu/drm/i915/i915_drv.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8039cec..4ecf85f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1630,11 +1630,9 @@ static int __init i915_init(void)
>
> if (!(driver.driver_features & DRIVER_MODESET)) {
> driver.get_vblank_timestamp = NULL;
> -#ifndef CONFIG_DRM_I915_UMS
> /* Silently fail loading to not upset userspace. */
> - DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
> + DRM_DEBUG_DRIVER("KMS disabled.\n");
> return 0;
> -#endif
> }
>
> /*
> @@ -1650,10 +1648,8 @@ static int __init i915_init(void)
>
> static void __exit i915_exit(void)
> {
> -#ifndef CONFIG_DRM_I915_UMS
> if (!(driver.driver_features & DRIVER_MODESET))
> return; /* Never loaded a driver. */
> -#endif
>
> drm_pci_exit(&driver, &i915_pci_driver);
> }
Thanks,
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank
Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]:
> this warning exist in v3.19-rc6 and does not in v3.18. Bisection
> points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait".
> I have two machines with integrated Intel graphics and the problem
> happens only on the old one with GM965 chipset and X3100 integrated graphics.
I see this too, since v3.19-rc1, on an (outdated) ThinkPad X41.
> backtrace information:
>
> [ 31.780813] WARNING: CPU: 0 PID: 718 at drivers/gpu/drm/drm_irq.c:1077
> drm_wait_one_vblank+0x33/0x141 [drm]()
But it also prints
vblank not available on crtc 0, ret=-22
after the WARNING line, on that machine.
> [ 31.780815] Modules linked in: ecb(E) i915(E+) snd_hda_codec_generic(E)
> coretemp(E) btusb(E) kvm_intel(E) snd_hda_intel(E) snd_hda_controller(E)
> kvm(E) drm_kms_helper(E) snd_hda_code
> c(E) snd_pcsp(E) bluetooth(E) snd_hwdep(E) drm(E) lpc_ich(E) evdev(E)
> mfd_core(E) snd_pcm(E) snd_timer(E) snd(E) psmouse(E) serio_raw(E)
> i2c_algo_bit(E) i2c_i801(E) rfkill(E) soundcore(
>
>
> E) battery(E) button(E) video(E) ac(E)
> i2ccore(E) acpi_cpufreq(E) processor(E) fuse(E) parport_pc(E) ppdev(E) lp(E)
> parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E) sd_mod(E) a
> ta_generic(E) ahci(E) libahci(E) sdhci_pci(E) sdhci(E) firewire_ohci(E)
> b44(E) mii(E) ssb(E) ata_piix(E) firewire_core(E) crc_itu_t(E) mmc_core(E)
> libphy(E) libata(E) scsi_mod(E) xhci_h
> cd(E) ehci_pci(E) uhci_hcd(E) ehci_hcd(E) usbcore(E) usb_common(E) thermal(E)
> [ 31.780862] thermal_sys(E)
> [ 31.780866] CPU: 0 PID: 718 Comm: kworker/u4:3 Tainted: GE
> 3.17.0-rc5-150116--00578-g51e31d4 #16
> [ 31.780868] Hardware name: Dell Inc. Vostro 1500
> /0NX907, BIOS A06 04/21/2008
> [ 31.780873] Workqueue: events_unbound async_run_entry_fn
> [ 31.780875] a0544b9d 813d4e81
>
> [ 31.780879] 8103dec3 8800d84e0068 a0521c73
> 00070008
> [ 31.780882] 8800d84e 8801973e0800
> 6014
> [ 31.780886] Call Trace:
> [ 31.780890] [] ? dump_stack+0x4a/0x75
> [ 31.780894] [] ? warn_slowpath_common+0x7e/0x97
> [ 31.781050] [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [ 31.781078] [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [ 31.781122] [] ? intel_enable_tv+0x22/0x58 [i915]
> [ 31.781153] [] ? i9xx_crtc_enable+0x33b/0x397 [i915]
> [ 31.781184] [] ? __intel_set_mode+0x1160/0x1209 [i915]
> [ 31.781216] [] ? intel_set_mode+0x12/0x2c [i915]
> [ 31.781247] [] ? intel_get_load_detect_pipe+0x367/0x408
> [i915]
> [ 31.781281] [] ? intel_tv_detect+0x103/0x444 [i915]
> [ 31.781289] [] ?
> drm_helper_probe_single_connector_modes_merge_bits+0xc0/0x327 [drm_kms_helper]
> [ 31.781296] [] ?
> drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper]
> [ 31.781303] [] ?
> drm_fb_helper_initial_config+0x3d/0x303 [drm_kms_helper]
> [ 31.781306] [] ? async_run_entry_fn+0x5a/0x110
> [ 31.781310] [] ? process_one_work+0x194/0x292
> [ 31.781313] [] ? worker_thread+0x236/0x298
> [ 31.781316] [] ? process_scheduled_works+0x2a/0x2a
> [ 31.781319] [] ? kthread+0x9e/0xa6
> [ 31.781322] [] ? kthread_freezable_should_stop+0x36/0x36
> [ 31.781326] [] ? ret_from_fork+0x7c/0xb0
> [ 31.781329] [] ? kthread_freezable_should_stop+0x36/0x36
> [ 31.782726] ---[ end trace e2b78017f1a10054 ]---
>
>
> lspci:
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
> GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 0c)
> 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (secondary) [8086:2a03] (rev 0c)
A naive revert, on top of v3.19-rc7, of commit 51e31d49c890552
("drm/i915: Use generic vblank wait") clashes with later changes. It
seems intel_wait_for_vblank() became an one line inline function in a
later commit.
Anyhow, is a fix for this queued somewhere?
Thanks,
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: "Wrong MCH_SSKPD value: 0x16040307"
0) A ThinkPad X220 I use prints these messages at every boot and at every resume: [drm] Wrong MCH_SSKPD value: 0x16040307 [drm] This can cause pipe underruns and display issues. [drm] Please upgrade your BIOS to fix this. These messages can be seen for every kernel that's still in the logs (the oldest is v3.11 based). 1) I'm not sure whether I actually run into "pipe underruns" or "display issues". Is there something specific I should look for? 2) Now it happens that this laptop already runs the latest BIOS. So, if I were to contact Lenovo to see if they could release a BIOS update to fix this, what should I ask them to do? Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: CONFIG_DRM_I915_UMS
On Sat, 2014-07-26 at 01:44 +0200, Daniel Vetter wrote:
> On Fri, Jul 25, 2014 at 2:14 PM, Paul Bolle wrote:
> > Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
> > included in today's linux-next (ie, next-20140725). It removes the
> > Kconfig symbol DRM_I915_UMS.
> >
> > It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
> > These checks are superfluous as they now will always evaluate to true.
> > Is the trivial cleanup to remove them already queued somewhere?
>
> No, and intentionally.
So this was not by mistake, which is good to know.
> Actually removing the code for
> user-mode-setting isn't just removing these two blocks,
Just to be clear: I'm only suggesting to remove the two lines reading
#ifndef CONFIG_DRM_I915_UMS
and their corresponding #endif lines.
> but requires
> the gutting of roughly 10k lines splattered all over the driver.
> Essentially all the code that checks for
> !drm_core_check_feature(DRIVER_MODESET) needs to go. That's not quite
> as trivial, and before I do that I want to make really sure that
> really no one misses this option.
>
> So probably after 3.17 is out the door for a bit.
None of what I brought up is urgent. But I do hope you don't mind me
sending a reminder if these few (preprocessor) lines are staying around
longer than expected.
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: CONFIG_DRM_I915_UMS
Daniel,
Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
included in today's linux-next (ie, next-20140725). It removes the
Kconfig symbol DRM_I915_UMS.
It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
These checks are superfluous as they now will always evaluate to true.
Is the trivial cleanup to remove them already queued somewhere?
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Track the primary plane correctly when reassigning planes
On Mon, 2014-07-14 at 19:39 +0200, Daniel Vetter wrote:
> commit 98ec77397a5c68ce753dc283aaa6f4742328bcdd
> Author: Ville Syrjälä
> Date: Wed Apr 30 17:43:01 2014 +0300
>
> drm/i915: Make primary_enabled match the actual hardware state
>
> introduced more accurate tracking of the primary plane and some
> checks. It missed the plane->pipe reassignement code for gen2/3
> though, which the checks caught and resulted in WARNING backtraces.
>
> Since we only use this path if the plane is on and on the wrong pipe
> we can just always set the tracking bit to "enabled".
>
> Reported-and-tested-by: Paul Bolle
Maybe that should be something like:
Reported-bisected-and-tested-by: Paul Bolle
> Cc: Paul Bolle
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 82e7d57f0a8a..f0be855ddf45 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11914,6 +11914,7 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc)
>* ... */
> plane = crtc->plane;
> crtc->plane = !plane;
> + crtc->primary_enabled = true;
> dev_priv->display.crtc_disable(&crtc->base);
> crtc->plane = plane;
>
(I don't do smilies. This is a joke!)
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
Daniel Vetter schreef op ma 14-07-2014 om 09:18 [+0200]: > On Mon, Jul 14, 2014 at 09:13:40AM +0200, Paul Bolle wrote: > > On Mon, 2014-07-14 at 08:56 +0200, Daniel Vetter wrote: > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index 82e7d57f0a8a..f0be855ddf45 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -11914,6 +11914,7 @@ static void intel_sanitize_crtc(struct intel_crtc > > > *crtc) > > >* ... */ > > > plane = crtc->plane; > > > crtc->plane = !plane; > > > + crtc->primary_enabled = true; > > > dev_priv->display.crtc_disable(&crtc->base); > > > crtc->plane = plane; > > > > > > > Instead of the revert or on top of the revert? > > Instead of the revert as an attempt at a proper bugfix. If it doesn't work > my theory about what's going on on your machine is all wrong ;-) v3.16-rc5 with that "attempt at a proper bugfix" applied doesn't show the WARNING anymore. Please note that I didn't actually bother to test whether v3.16-rc5 by itself, somehow, fixed things. I guess that's rather unlikely. But if you'd like to be sure I'll even build and boot v3.16-rc5 without your attempt at a bugfix. Thanks! Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
On Mon, 2014-07-14 at 08:56 +0200, Daniel Vetter wrote: > Please test the below patch, thanks. > -Daniel > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 82e7d57f0a8a..f0be855ddf45 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -11914,6 +11914,7 @@ static void intel_sanitize_crtc(struct intel_crtc > *crtc) >* ... */ > plane = crtc->plane; > crtc->plane = !plane; > + crtc->primary_enabled = true; > dev_priv->display.crtc_disable(&crtc->base); > crtc->plane = plane; > Instead of the revert or on top of the revert? Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
Paul Bolle schreef op wo 02-07-2014 om 10:53 [+0200]:
> On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote:
> > This does not ring any bells to me (but that doesn't prove anything). A
> > bisect result would be awesome.
The bisect (which took me quite some time) points at commit 98ec77397a5c
("drm/i915: Make primary_enabled match the actual hardware state"). The
bisect log is pasted at the end of this message.
Commit 98ec77397a5c reverts cleanly on top of v3.16-rc4. Booting
v3.16-rc4 with that revert added makes the WARNING go away. But note
that I have no idea whether that revert actually is a proper fix here.
Feel free to prod me for further testing, etc.
Paul Bolle
# bad: [7171511eaec5bf23fb06078f59784a3a0626b38f] Linux 3.16-rc1
# good: [1860e379875dfe7271c649058aeddffe5afd9d0d] Linux 3.15
git bisect start 'v3.16-rc1' 'v3.15'
# good: [aaeb2554337217dfa4eac2fcc90da7be540b9a73] Merge branch 'v4l_for_linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media into next
git bisect good aaeb2554337217dfa4eac2fcc90da7be540b9a73
# good: [16b9057804c02e2d351e9c8f606e909b43cbd9e7] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good 16b9057804c02e2d351e9c8f606e909b43cbd9e7
# good: [249c8b8d7e2d1bf9505dc46458537e77326c24fd] i40evf: remove unnecessary
log messages
git bisect good 249c8b8d7e2d1bf9505dc46458537e77326c24fd
# bad: [1ae5a62bb8b6b544bdfac7bdcb15c9eb22dd6620] drm/nouveau/disp/dp: fix tmds
passthrough on dp connector
git bisect bad 1ae5a62bb8b6b544bdfac7bdcb15c9eb22dd6620
# bad: [cea165c34502052cb2aafc7e6bb36fe2036a19df] drm/i915: Wait for vblank in
hsw_enable_ips()
git bisect bad cea165c34502052cb2aafc7e6bb36fe2036a19df
# good: [e6069ca84dfafbfdbd0d429445b5858ec5b090ac] drm/i915: sanitize
enable_rc6 option
git bisect good e6069ca84dfafbfdbd0d429445b5858ec5b090ac
# bad: [aff10b30a1d3edd1e31f536648772da85e33f655] drm/i915: Don't drop pinned
fences
git bisect bad aff10b30a1d3edd1e31f536648772da85e33f655
# bad: [3f1d896c61e889e5b1a0cc0c0211574fa76feefb] drm/i915/chv: Enable aliasing
PPGTT for CHV
git bisect bad 3f1d896c61e889e5b1a0cc0c0211574fa76feefb
# good: [0d116a29a8f80260380f608c033dba42240e26a8] drm/i915: vlv: init only
needed state during early power well enabling
git bisect good 0d116a29a8f80260380f608c033dba42240e26a8
# bad: [894ed1ec4818ad12e5254de33de2fe5cf2ab987b] drm/i915/crt: Remove
->mode_set callback
git bisect bad 894ed1ec4818ad12e5254de33de2fe5cf2ab987b
# bad: [912b0e2dc6779d70a549dc90b0884face3b2540a] drm/i915/dvo: Remove
->mode_set callback
git bisect bad 912b0e2dc6779d70a549dc90b0884face3b2540a
# good: [024a43e12cccd13b7336fc71ab2067a19ade1857] drm/i915: Move ring_begin to
signal()
git bisect good 024a43e12cccd13b7336fc71ab2067a19ade1857
# bad: [0d56bf0b65e6930ea00060d4107414b8d74c9055] drm/i915: Make
encoder->mode_set callbacks optional
git bisect bad 0d56bf0b65e6930ea00060d4107414b8d74c9055
# bad: [98ec77397a5c68ce753dc283aaa6f4742328bcdd] drm/i915: Make
primary_enabled match the actual hardware state
git bisect bad 98ec77397a5c68ce753dc283aaa6f4742328bcdd
# first bad commit: [98ec77397a5c68ce753dc283aaa6f4742328bcdd] drm/i915: Make
primary_enabled match the actual hardware state
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote: > This does not ring any bells to me (but that doesn't prove anything). A > bisect result would be awesome. Too bad. Unless someone else has a better idea I hope to start bisecting one of these days (that might take quite some time, especially since I can't yet narrow the bisect to changes in drivers/gpu/drm/i915/, can I?). Don't expect results before v3.16-rc4. Feel free to remind me if I stay silent on this subject for too long. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
Kernels v3.16-rc2 and v3.16-rc3 trigger a new (for me) warning. (I never booted v3.16-rc1). Machine is a, rather outdated, ThinkPad X41 (ie, single core i686). WARNING: CPU: 0 PID: 221 at drivers/gpu/drm/i915/intel_display.c:1274 assert_planes_disabled+0xf9/0x100 [i915]() plane B assertion failure, should be off on pipe B but is still active Modules linked in: tg3 i915(+) i2c_algo_bit drm_kms_helper ptp drm ata_generic pata_acpi yenta_socket i2c_core pps_core video CPU: 0 PID: 221 Comm: systemd-udevd Not tainted 3.16.0-0.rc3.1.local0.fc20.i686 #1 Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW (2.09 ) 12/14/2006 c0c87907 add7c490 f652b9ac c09fdab7 f652b9ec f652b9dc c045008e f830c6cc f652ba0c 00dd f830c634 04fa f82b4d59 f82b4d59 f6728000 0001 f65a8c00 f652b9f8 c04500ee 0009 f652b9ec f830c6cc f652ba0c Call Trace: [] dump_stack+0x41/0x52 [] warn_slowpath_common+0x7e/0xa0 [] ? assert_planes_disabled+0xf9/0x100 [i915] [] ? assert_planes_disabled+0xf9/0x100 [i915] [] warn_slowpath_fmt+0x3e/0x60 [] assert_planes_disabled+0xf9/0x100 [i915] [] intel_disable_pipe+0x26/0xb0 [i915] [] ? gen4_read8+0xc0/0xc0 [i915] [] i9xx_crtc_disable+0x93/0x3d0 [i915] [] intel_modeset_setup_hw_state+0x7ac/0xbc0 [i915] [] ? gen4_read8+0xc0/0xc0 [i915] [] ? drm_modeset_lock_all_crtcs+0x3c/0x50 [drm] [] intel_modeset_init+0x734/0x1220 [i915] [] ? i915_enable_pipestat+0xab/0x120 [i915] [] ? i915_irq_postinstall+0x104/0x110 [i915] [] ? drm_irq_install+0xa9/0x170 [drm] [] i915_driver_load+0xa76/0xe70 [i915] [] ? i915_switcheroo_set_state+0x90/0x90 [i915] [] ? cleanup_uevent_env+0x10/0x10 [] ? sysfs_add_file+0x23/0x30 [] ? get_device+0x14/0x30 [] ? klist_class_dev_get+0x12/0x20 [] ? klist_node_init+0x2e/0x50 [] ? klist_add_tail+0x27/0x30 [] ? device_add+0x1d6/0x5a0 [] ? drm_sysfs_device_add+0xba/0x100 [drm] [] drm_dev_register+0x8e/0xe0 [drm] [] drm_get_pci_dev+0x79/0x1c0 [drm] [] i915_pci_probe+0x35/0x60 [i915] [] pci_device_probe+0x6f/0xc0 [] ? sysfs_create_link+0x25/0x40 [] driver_probe_device+0x93/0x3a0 [] ? sysfs_create_dir_ns+0x37/0x80 [] ? pci_match_device+0xc1/0xe0 [] __driver_attach+0x71/0x80 [] ? __device_attach+0x40/0x40 [] bus_for_each_dev+0x57/0xa0 [] driver_attach+0x1e/0x20 [] ? __device_attach+0x40/0x40 [] bus_add_driver+0x157/0x230 [] ? 0xf7fc7fff [] ? 0xf7fc7fff [] driver_register+0x59/0xe0 [] ? __kmalloc_track_caller+0x46/0x1f0 [] __pci_register_driver+0x32/0x40 [] drm_pci_init+0xe5/0x110 [drm] [] ? 0xf7fc7fff [] i915_init+0x88/0x8a [i915] [] ? 0xf7fc7fff [] do_one_initcall+0xc2/0x1f0 [] ? 0xf7fc7fff [] ? kfree+0xdd/0x120 [] ? __vunmap+0x8f/0xe0 [] ? __vunmap+0x8f/0xe0 [] ? __vunmap+0x8f/0xe0 [] load_module+0x1a92/0x23b0 [] ? copy_module_from_fd.isra.46+0x109/0x1a0 [] SyS_finit_module+0x8d/0xd0 [] ? vm_mmap_pgoff+0x93/0xb0 [] sysenter_do_call+0x12/0x16 Feel free to prod me for further details. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
Bjorn Helgaas schreef op ma 10-03-2014 om 20:07 [-0600]: > On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle wrote: > > On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote: > >> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote: > >> > A bit of doubt is caused by two new boot time messages: > >> > pnp 00:00: unknown resource type 10 in _CRS > >> > pnp 00:00: can't evaluate _CRS: 1 > >> > > >> > But I haven't yet tried v3.14-rc6 without your patch, so these might be > >> > unrelated. They're unclear to me, anyway. > >> > >> Hmm, this is definitely concerning. Resource type 10 is > >> ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's > >> length 0). And your previous dmesg logs (at > >> https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything > >> like that. > >> > >> Can you attach an acpidump and the dmesg log with my patch to the bugzilla? > > > > It's getting rather late over here. So I'll try (quite) a few hours > > later. But acpidump doesn't ring any bells right now. Any hints? > > There's acpidump info here: https://01.org/linux-acpi/utilities . You > don't need to extract the binary tables or anything; just attach the > text dump to the bugzilla. (On Fedora it's shipped in acpica-tools. But since acpidump is a symlink to /usr/bin/acpidump-acpica that is created at install time it won't show up when one does "repoquery -f "*/acpidump". Add to this that "yum list pmtools" returns an error, and one is guaranteed roughly 30 minutes of sheer fun. Unsurprisingly, stubbornly trying "yum install pmtools" will actually install acpica-tools.) At least this all is written down somewhere now.) > It would be very interesting to try v3.14-rc6 without my patch. I > hope it has the same "unknown resource type" messages, because I don't > see how my patch could be related to them. There were no recent > PNP-related changes, so then I start to worry about some sort of > memory corruption from an unrelated patch. But I hope that's not the > case. lkml.org is returning some error page, but Markus Trippelsdorf just reported seeing this message too. Markus is unlikely to be also trying this patch. I've just added you to the CC's of my reply to Markus. I won't update the bugzilla report for now, because those messages appear unrelated to your patch. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote: > On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote: > > A bit of doubt is caused by two new boot time messages: > > pnp 00:00: unknown resource type 10 in _CRS > > pnp 00:00: can't evaluate _CRS: 1 > > > > But I haven't yet tried v3.14-rc6 without your patch, so these might be > > unrelated. They're unclear to me, anyway. > > Hmm, this is definitely concerning. Resource type 10 is > ACPI_RESOURCE_TYPE_FIXED_MEMORY32, which we do handle (unless it's > length 0). And your previous dmesg logs (at > https://bugzilla.kernel.org/show_bug.cgi?id=71611) don't show anything > like that. > > Can you attach an acpidump and the dmesg log with my patch to the bugzilla? It's getting rather late over here. So I'll try (quite) a few hours later. But acpidump doesn't ring any bells right now. Any hints? Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
Bjorn Helgaas schreef op ma 10-03-2014 om 12:24 [-0600]: > Thanks. Can you try the patch below? I think it should fix the problem. > > > PCI: Don't check resource_size() in pci_bus_alloc_resource() > > From: Bjorn Helgaas > > When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_T_64BIT > is not defined, resource_size() on [mem 0x-0x] returns 0 > because (r->end - r->start + 1) overflows. > > Therefore, we can't use "resource_size() == 0" to decide that allocation > from this resource will fail. allocate_resource() should fail anyway if it > can't satisfy the address constraints, so we should just depend on that. > > A [mem 0x-0x] bus resource is obviously not really valid, > but we do fall back to it as a default when we don't have information about > host bridge apertures. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611 > Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation > Signed-off-by: Bjorn Helgaas > --- > drivers/pci/bus.c |2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c > index 00660cc502c5..38901665c770 100644 > --- a/drivers/pci/bus.c > +++ b/drivers/pci/bus.c > @@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, > struct resource *res, > > avail = *r; > pci_clip_resource_to_region(bus, &avail, region); > - if (!resource_size(&avail)) > - continue; > > /* >* "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to I've applied your patch on top of v3.14-rc6. The boot warning is gone. And /proc/iomem once again has the lines: [...] 8000-801f : PCI Bus :02 8020-8027 : :00:02.1 8028-80280fff : Intel Flush Page [...] Which is what we want, don't we? A bit of doubt is caused by two new boot time messages: pnp 00:00: unknown resource type 10 in _CRS pnp 00:00: can't evaluate _CRS: 1 But I haven't yet tried v3.14-rc6 without your patch, so these might be unrelated. They're unclear to me, anyway. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
Bjorn Helgaas schreef op za 08-03-2014 om 07:12 [-0700]: > I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly > legal); let me know if otherwise. $ grep CONFIG_PHYS_ADDR_T_64BIT /boot/config-3.14.0-0.rc5.1.local2.fc20.i686 # CONFIG_PHYS_ADDR_T_64BIT is not set So, yes, CONFIG_PHYS_ADDR_T_64BIT=n here. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
On Fri, 2014-03-07 at 13:40 -0700, Bjorn Helgaas wrote:
> It seems quite possible that I broke pci_bus_alloc_resource(), which could
> cause an allocation failure like this.
>
> If you have a chance to try it, here's a debug patch against v3.14-rc5. It
> should apply cleanly to 96702be56037. If you can try it, please attach the
> dmesg log to the bugzilla.
That ThinkPad X41 is now building 96702be56037. Once that build is
finished and tested I'll try your debug patch (on top of v3.14-rc5, see
later). It might take some time to finish both builds and test boots.
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 5c85350f4c3d..0dbba6c7c001 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -997,6 +997,7 @@ static int intel_alloc_chipset_flush_resource(void)
> ret = pci_bus_alloc_resource(intel_private.bridge_dev->bus,
> &intel_private.ifp_resource, PAGE_SIZE,
>PAGE_SIZE, PCIBIOS_MIN_MEM, 0,
>pcibios_align_resource,
> intel_private.bridge_dev);
> + dev_info(&intel_private.bridge_dev->dev, "pci_bus_alloc ret %d\n", ret);
>
> return ret;
> }
> @@ -1007,6 +1008,7 @@ static void intel_i915_setup_chipset_flush(void)
> u32 temp;
>
> pci_read_config_dword(intel_private.bridge_dev, I915_IFPADDR, &temp);
> + dev_info(&intel_private.bridge_dev->dev, "I915_IFPADDR %#010x\n", temp);
> if (!(temp & 0x1)) {
> intel_alloc_chipset_flush_resource();
> intel_private.resource_valid = 1;
> @@ -1022,6 +1024,7 @@ static void intel_i915_setup_chipset_flush(void)
> if (ret)
> intel_private.resource_valid = 0;
> }
> + dev_info(&intel_private.bridge_dev->dev, "ifp_resource %pR\n",
> &intel_private.ifp_resource);
> }
>
> static void intel_i965_g33_setup_chipset_flush(void)
My v3.13 based builds don't have INTEL_GTT set! My v3.14-rcy based
builds do. I have not yet investigated why that is.
(Note that the .config on that ThinkPad X41 is - in short - rebranched
from the kernel .config that is shipped for Fedora 20 every time a rc1
is released.)
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 00660cc502c5..1c6d75ae34d9 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -146,24 +146,31 @@ static int pci_bus_alloc_from_region(struct pci_bus
> *bus, struct resource *res,
>
> type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
>
> + dev_info(&bus->dev, "%s: alloc %pR size %#llx from bus region
> [%#010llx-%#010llx]\n", __func__, res, (long long) size, (long long)
> region->start, (long long) region->end);
> pci_bus_for_each_resource(bus, r, i) {
> if (!r)
> continue;
>
> /* type_mask must match */
> - if ((res->flags ^ r->flags) & type_mask)
> + if ((res->flags ^ r->flags) & type_mask) {
> + dev_info(&bus->dev, "%s: %pR: wrong type (%#lx %#lx
> mask %#x)\n", __func__, r, res->flags, r->flags, type_mask);
> continue;
> + }
>
> /* We cannot allocate a non-prefetching resource
> from a pre-fetching area */
> if ((r->flags & IORESOURCE_PREFETCH) &&
> - !(res->flags & IORESOURCE_PREFETCH))
> + !(res->flags & IORESOURCE_PREFETCH)) {
> + dev_info(&bus->dev, "%s: %pR: wrong prefetchability\n",
> __func__, r);
> continue;
> + }
>
> avail = *r;
> pci_clip_resource_to_region(bus, &avail, region);
> - if (!resource_size(&avail))
> + if (!resource_size(&avail)) {
> + dev_info(&bus->dev, "%s: %pR: no space (avail %pR)\n",
> __func__, r, &avail);
> continue;
> + }
>
> /*
>* "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to
> @@ -179,6 +186,7 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus,
> struct resource *res,
> /* Ok, try it out.. */
> ret = allocate_resource(r, res, size, min, max,
> align, alignf, alignf_data);
> + dev_info(&bus->dev, "%s: %pR: alloc from %#llx-%#llx, ret
> %d\n", __func__, r, min, max, ret);
> if (ret == 0)
> return 0;
> }
Too bad drivers/pci/bus.o is built in by definition. If only one could
build a kernel without rebuilding all modules. Or is there some way to
actually do that?
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]: > On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote: > > This might end up not being relevant. And this is surely documented > > somewhere, but anyhow: > > - what git magic returns the hashes of the 15 commits that merge commit > > 96702be56037 added to the tree; and > > "git show 96702be56037" gives: > > commit 96702be560374ee7e7139a34cab03554129abbb4 > Merge: 04f982beb900 d56dbf5bab8c > ... > > 04f982beb900 is the previous HEAD, d56dbf5bab8c is the head of the > branch merged by this commit. "git log 04f982beb900..96702be56037" > shows the commits merged. Thanks. Fairly obvious, actually. Not sure why I didn't think of this myself. > > - how can I use the list of those hashes to limit the range of commits > > to do a git bisect? > > I'm not a git bisect expert, but I *think* you should be able to do > something like this: > > git bisect start > git bisect bad 96702be56037 > git bisect good 04f982beb900 > > (assuming you've verified that 96702be56037 really *is* bad and > 04f982beb900 really *is* good), and git should checkout something in > the middle and you can build and test it, then use "git bisect good" > or "git bisect bad" depending on the result. Makes sense. Thanks again. 04f982beb900 appears to be good. So if 96702be56037 turns out to be bad bisecting might not turn into the ordeal it usually is. (On this machine, with my workflow, bisecting an v3.x..v3.x+1-rcy range takes a few days.) Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: > I wouldn't start bisecting yet, but if you're in the mood, this > commit: 96702be56037 "Merge branch 'pci/resource' into next" looks > like a good place to start, so you could try the pre-merge commit: > 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is > good, there are only about 15 commits on the pci/resource branch to > look at. This might end up not being relevant. And this is surely documented somewhere, but anyhow: - what git magic returns the hashes of the 15 commits that merge commit 96702be56037 added to the tree; and - how can I use the list of those hashes to limit the range of commits to do a git bisect? Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: > Can you open a kernel.org bugzilla report and attach complete dmesg > logs of the working and broken kernels to it? There might be more > useful resource-related messages from the PCI core. That took me quite a bit longer than I hoped, but I finally opened a report at https://bugzilla.kernel.org/show_bug.cgi?id=71611 . Note that the dmesg's are identical (up to that error). Are you still interested? > I wouldn't start bisecting yet, but if you're in the mood, this > commit: 96702be56037 "Merge branch 'pci/resource' into next" looks > like a good place to start, so you could try the pre-merge commit: > 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is > good, there are only about 15 commits on the pci/resource branch to > look at. I hope to do a bisect in the next few days. If that bisect pinpoints an interesting commit that might just be in time for v3.14. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.13 i915 brightness settings broken when going from docked -> undocked
On Tue, 2014-02-25 at 10:05 +0200, Jani Nikula wrote: > On Thu, 20 Feb 2014, Paul Bolle wrote: > > On an (rather old) ThinkPad X41, which also uses i915, brightness > > adjustments stopped working altogether in v3.14-rc1 (I haven't used its > > docking station in the v3.14 release cycle). In v3.13.y things behave as > > expected. So perhaps there's actually a more general problem here. > > I presume different problems. Does the ThinkPad X41 have gen3 graphics? > (See e.g. /sys/kernel/debug/dri/0/i915_capabilities) If yes, it might be > https://bugs.freedesktop.org/show_bug.cgi?id=75001 Yes, it has "gen3" graphics (a 915GM). And applying your patch "drm/i915: use backlight legacy combination mode also for i915gm/i945/gm" on top of v3.14-rc5 fixes the issue on that ThinkPad X41. Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.13 i915 brightness settings broken when going from docked -> undocked
On Wed, 2014-02-19 at 21:20 -0500, Josh Boyer wrote: > We've had a rather weird report[1] of the brightness adjustments being > broken in a specific case with Thinkpad x220 hardware (SandyBridge > based). If you boot the machine with it in a dock and then undock, > the brightness adjustments do not work. That is with either the FN > keys or the GNOME brightness slider. On an (rather old) ThinkPad X41, which also uses i915, brightness adjustments stopped working altogether in v3.14-rc1 (I haven't used its docking station in the v3.14 release cycle). In v3.13.y things behave as expected. So perhaps there's actually a more general problem here. > I can see that the value of > /sys/class/backlight/acpi_video0/brightness On the X41 I check /proc/acpi/ibm/brightness ... > increases/decreases but > /sys/class/backlight/intel_backlight/brightness doesn't reflect any > changes. but otherwise things look similar. > With 3.12 this works, and oddly with 3.14-rc1 it works > (specifically, it starts working around v3.13-10231-g53d8ab2 which is > right after the first DRM merge for 3.14). With 3.13, if I undock and > echo a higher value in the intel_backlight_brightness sysfs entry, the > brightness will actually increase so it can be done manually, but it > does not work as you'd expect. Echoing values into /sys/class/backlight/intel_backlight/brightness works too (that's a new trick for me!). But, again, no docking station is required, so the problem looks less odd than the problem on that x220. > I'm in the middle of trying to do a reverse bisect for which patch > fixes it in the 3.14-rcX series, but that's taking a while. I thought > I'd email and see if anyone already knows about this situation, what > patch in 3.13 broke this, and which one then fixed it again. Thus far > all I've gathered is that backlight handling is confusing. I haven't yet tried bisecting. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1067071 Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote: > PCI resource allocation is undergoing some changes at the moment, it's > definitely a bug if the Flush Page isn't getting allocated. I'm looking > forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in > mainline, it will provide much better resource allocation in the 32 bit > PCI address space, and prevent problems like this from cropping up. > > See Yinghai Lu's for-pci-res-alloc branch. > > I've been carrying the changes in my local tree, but right now the > upstream PCI changes are quite extensive. He's planning on rebasing the > branch soon. Does this mean I might be better of not bisecting this just yet? Or are these changes targeted at v3.15 (or later)? Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
0-a7ff : PCI CardBus :05 c000-cfff : :00:02.0 d000-d7ff : PCI Bus :04 d000-d3ff : PCI CardBus :05 e000-efff : PCI MMCONFIG [bus 00-ff] e000-efff : reserved e000-efff : pnp 00:01 f0008000-f000bfff : reserved f0008000-f000bfff : pnp 00:01 f000b410-f000b414 : iTCO_wdt f000b410-f000b414 : iTCO_wdt fec0-fec0 : reserved fec0-fec003ff : IOAPIC 0 fed14000-fed19fff : reserved fed14000-fed17fff : pnp 00:01 fed18000-fed18fff : pnp 00:01 fed19000-fed19fff : pnp 00:01 fed2-fed8 : reserved fee0-fee00fff : Local APIC fee0-fee00fff : reserved ff000000- : reserved Thanks, Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Tue, 2013-12-03 at 16:19 +0100, Daniel Vetter wrote: > I'd like to confirm the actual cause (I suspect that we switch > pipes&planes around) for why you see this but other machines don't show > this to augment the commit message. But I've merged the fix already. The dmesg, up to and including the WARNING, is attached. Have fun! Paul Bolle <6>[0.00] Initializing cgroup subsys cpuset <6>[0.00] Initializing cgroup subsys cpu <6>[0.00] Initializing cgroup subsys cpuacct <5>[0.00] Linux version 3.13.0-0.rc2.1.local1.fc18.i686 ([...]) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Sun Dec 1 11:58:49 CET 2013 <6>[0.00] Disabled fast string operations <6>[0.00] e820: BIOS-provided physical RAM map: <6>[0.00] BIOS-e820: [mem 0x-0x0009efff] usable <6>[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved <6>[0.00] BIOS-e820: [mem 0x000d-0x000d3fff] reserved <6>[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved <6>[0.00] BIOS-e820: [mem 0x0010-0x7f6d] usable <6>[0.00] BIOS-e820: [mem 0x7f6e-0x7f6f4fff] ACPI data <6>[0.00] BIOS-e820: [mem 0x7f6f5000-0x7f6f] ACPI NVS <6>[0.00] BIOS-e820: [mem 0x7f70-0x7fff] reserved <6>[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved <6>[0.00] BIOS-e820: [mem 0xf0008000-0xf000bfff] reserved <6>[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved <6>[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved <6>[0.00] BIOS-e820: [mem 0xfed2-0xfed8] reserved <6>[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved <6>[0.00] BIOS-e820: [mem 0xff00-0x] reserved <5>[0.00] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! <6>[0.00] SMBIOS 2.3 present. <7>[0.00] DMI: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <7>[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved <7>[0.00] e820: remove [mem 0x000a-0x000f] usable <6>[0.00] e820: last_pfn = 0x7f6e0 max_arch_pfn = 0x10 <7>[0.00] MTRR default type: uncachable <7>[0.00] MTRR fixed ranges enabled: <7>[0.00] 0-9 write-back <7>[0.00] A-B uncachable <7>[0.00] C-C write-protect <7>[0.00] D-DBFFF uncachable <7>[0.00] DC000-D write-back <7>[0.00] E-F write-protect <7>[0.00] MTRR variable ranges enabled: <7>[0.00] 0 base 0 mask F8000 write-back <7>[0.00] 1 base 07F70 mask 0 uncachable <7>[0.00] 2 base 07F80 mask FFF80 uncachable <7>[0.00] 3 disabled <7>[0.00] 4 disabled <7>[0.00] 5 disabled <7>[0.00] 6 disabled <7>[0.00] 7 disabled <6>[0.00] PAT not supported by CPU. <7>[0.00] initial memory mapped: [mem 0x-0x013f] <7>[0.00] Base memory trampoline at [c009b000] 9b000 size 16384 <6>[0.00] init_memory_mapping: [mem 0x-0x000f] <7>[0.00] [mem 0x-0x000f] page 4k <6>[0.00] init_memory_mapping: [mem 0x36c0-0x36ff] <7>[0.00] [mem 0x36c0-0x36ff] page 2M <6>[0.00] init_memory_mapping: [mem 0x3000-0x36bf] <7>[0.00] [mem 0x3000-0x36bf] page 2M <6>[0.00] init_memory_mapping: [mem 0x0010-0x2fff] <7>[0.00] [mem 0x0010-0x003f] page 4k <7>[0.00] [mem 0x0040-0x2fff] page 2M <6>[0.00] init_memory_mapping: [mem 0x3700-0x373fdfff] <7>[0.00] [mem 0x3700-0x373fdfff] page 4k <7>[0.00] BRK [0x00e6d000, 0x00e6dfff] PGTABLE <7>[0.00] BRK [0x00e6e000, 0x00e6] PGTABLE <6>[0.00] RAMDISK: [mem 0x33f7c000-0x35fb5fff] <5>[0.00] ACPI: RSDP 000f6c00 24 (v02 IBM ) <5>[0.00] ACPI: XSDT 7f6e4770 5C (v01 IBMTP-742060 LTP ) <5>[0.00] ACPI: FACP 7f6e4800 F4 (v03 IBMTP-742060 IBM 0001) <5>[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20131115/tbfadt-572) <5>[0.00] ACP
[Intel-gfx] [i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On both v3.13-rc1 and v3.13-rc2 is see this at every boot and during every suspend and resume cycle: <4>[2.682468] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector+0x42/0x50 [i915]() <5>[2.682470] Modules linked in: i915(F+) ata_generic(F) pata_acpi(F) yenta_socket(F+) i2c_algo_bit(F) drm_kms_helper(F) tg3(F+) ptp(F) pps_core(F) drm(F) i2c_core(F) video(F) sunrpc(F) <5>[2.682489] CPU: 0 PID: 173 Comm: systemd-udevd Tainted: GF 3.13.0-0.rc2.1.local0.fc18.i686 #1 <5>[2.682492] Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <5>[2.682495] f54739f4 c09b66d2 f5473a24 c0449b14 c0b541a4 <5>[2.682502] 00ad f82c9524 26dc f8282692 f8282692 f555ed80 00061200 <5>[2.682509] f567c000 f5473a34 c0449b52 0009 f5473a40 f8282692 f5578800 <5>[2.682516] Call Trace: <5>[2.682528] [] dump_stack+0x41/0x52 <5>[2.682534] [] warn_slowpath_common+0x84/0xa0 <5>[2.682571] [] ? intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682607] [] ? intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682612] [] warn_slowpath_null+0x22/0x30 <5>[2.682648] [] intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682689] [] intel_panel_disable_backlight+0x21/0x160 [i915] <5>[2.682725] [] intel_disable_lvds+0x41/0x160 [i915] <5>[2.682760] [] i9xx_crtc_disable+0x200/0x2c0 [i915] <5>[2.682802] [] ? gen4_read32+0x31/0x90 [i915] <5>[2.682839] [] intel_modeset_setup_hw_state+0x92e/0xb00 [i915] <5>[2.682844] [] ? power_down+0x8c/0x8d <5>[2.682884] [] ? gen4_write64+0xa0/0xa0 [i915] <5>[2.682920] [] intel_modeset_gem_init+0x20/0x30 [i915] <5>[2.682950] [] i915_driver_load+0xb53/0xdd0 [i915] <5>[2.682978] [] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] <5>[2.683003] [] drm_dev_register+0x8c/0x1a0 [drm] <5>[2.683043] [] drm_get_pci_dev+0x85/0x130 [drm] <5>[2.683050] [] ? sysfs_do_create_link_sd.isra.3+0xa8/0x1c0 <5>[2.683057] [] ? notifier_call_chain+0x43/0x60 <5>[2.683086] [] i915_pci_probe+0x3a/0x80 [i915] <5>[2.683093] [] pci_device_probe+0x79/0xc0 <5>[2.683097] [] ? sysfs_create_link+0x25/0x40 <5>[2.683104] [] driver_probe_device+0x79/0x360 <5>[2.683108] [] ? pci_match_device+0x9e/0xb0 <5>[2.683113] [] __driver_attach+0x91/0xa0 <5>[2.683117] [] ? driver_probe_device+0x360/0x360 <5>[2.683121] [] bus_for_each_dev+0x42/0x80 <5>[2.683125] [] driver_attach+0x1e/0x20 <5>[2.683130] [] ? driver_probe_device+0x360/0x360 <5>[2.683134] [] bus_add_driver+0xec/0x210 <5>[2.683138] [] driver_register+0x59/0xe0 <5>[2.683142] [] ? 0xf7fb1fff <5>[2.683147] [] __pci_register_driver+0x33/0x40 <5>[2.683150] [] ? 0xf7fb1fff <5>[2.683166] [] drm_pci_init+0xfd/0x110 [drm] <5>[2.683170] [] ? 0xf7fb1fff <5>[2.683198] [] i915_init+0x5e/0x60 [i915] <5>[2.683203] [] do_one_initcall+0xda/0x1a0 <5>[2.683206] [] ? 0xf7fb1fff <5>[2.683211] [] ? __add_event_to_tracers+0x21/0x30 <5>[2.683215] [] ? 0xf7fb1fff <5>[2.683221] [] ? set_memory_ro+0x37/0x40 <5>[2.683228] [] load_module+0x1abd/0x2390 <5>[2.683235] [] SyS_init_module+0xa7/0x110 <5>[2.683242] [] ? vm_mmap_pgoff+0x8b/0xb0 <5>[2.683248] [] sysenter_do_call+0x12/0x28 Feel free to prod for further details. Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Sun, 2013-12-01 at 10:58 +0100, Daniel Vetter wrote: > Should be fixed with > > commit 7c063c725987406d743cc7de7625ff224fab75de > Author: Jesse Barnes > Date: Tue Nov 26 09:13:41 2013 -0800 > > drm/i915: take mode config lock around crtc disable at suspend > > which is currently in drm-intel-fixes. I'll forward it early next week. Thanks! The WARNING is now gone during suspend and resume (having tested that thoroughly - ie, twice). But I still see it at boot. Is there a related fix for that WARNING during boot? Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Mon, 2013-12-02 at 15:23 +0100, Daniel Vetter wrote: > On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle wrote: > > This generated quite a bit of debug messages so I only copied the > > WARNING and the drm (related) messages immediately preceding it. Please > > feel free to prod again if that's insufficient. > > Yeah, the beginning of the drm message would are wanted since I need > to know what exactly your hardware claims to support ;-) > > But the backtrace confirms my first hunch for now ... Just want to > confirm before sending out a patch with commit message. It seems Ville's patch ( https://lkml.org/lkml/2013/12/2/77 ) does the trick. Do you still need the additional info? Paul Bolle ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
On Mon, 2013-12-02 at 11:08 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Some lower level things get angry if we don't have modeset locks
> during intel_modeset_setup_hw_state(). Actually the resume and
> lid_notify codepaths alreday hold the locks, but the init codepath
> doesn't, so fix that.
>
> Signed-off-by: Ville Syrjälä
> ---
> Totally untested, but looks correct to me.
I assume I need to test this, on top of 7c063c725987 ("drm/i915: take
mode config lock around crtc disable at suspend"), to see if this makes
the WARNING that I currently see at boot go away?
Paul Bolle
> drivers/gpu/drm/i915/intel_display.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 080f6fd..114db51 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11046,7 +11046,9 @@ void intel_modeset_gem_init(struct drm_device *dev)
>
> intel_setup_overlay(dev);
>
> + drm_modeset_lock_all(dev);
> intel_modeset_setup_hw_state(dev, false);
> + drm_modeset_unlock_all(dev);
> }
>
> void intel_modeset_cleanup(struct drm_device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
On Mon, 2013-12-02 at 14:12 +0200, Ville Syrjälä wrote:
> On Mon, Dec 02, 2013 at 11:00:29AM +0100, Paul Bolle wrote:
> > I assume I need to test this, on top of 7c063c725987 ("drm/i915: take
> > mode config lock around crtc disable at suspend"), to see if this makes
> > the WARNING that I currently see at boot go away?
>
> Yeah that would be nice.
A grand total of one boot suggests that this patch really makes the
v3.13+ WARNING go away at boot too. Should I test more thoroughly?
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Mon, 2013-12-02 at 08:33 +0100, Daniel Vetter wrote: > On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle wrote: > > The WARNING is now gone during suspend and resume (having tested that > > thoroughly - ie, twice). But I still see it at boot. Is there a related > > fix for that WARNING during boot? > > Hm, I've never seen it during boot. Can you please boot with > drm.debug=0xe and attach the dmesg with the WARN? Sure. This generated quite a bit of debug messages so I only copied the WARNING and the drm (related) messages immediately preceding it. Please feel free to prod again if that's insufficient. [...] <6>[2.727041] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 <7>[2.729161] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus panel <7>[2.729166] [drm:intel_lvds_init], using mode from VBT: <7>[2.729170] [drm:drm_mode_debug_printmodeline], <5>[2.729175] Modeline 0:"1024x768" 0 54160 1024 1048 1184 1344 768 771 777 806 0x8 0xa <7>[2.729464] [drm:intel_lvds_init], detected single-link lvds configuration <7>[2.729575] [drm:intel_panel_get_backlight], get backlight PWM = 13875 <7>[2.729579] [drm:intel_panel_get_max_backlight], max backlight PWM = 13875 <7>[2.729732] [drm:i915_gem_setup_global_gtt], clearing unused GTT space: [0, 000] <7>[2.733459] [drm:i915_gem_object_create_stolen], creating stolen object: size=2 <7>[2.733466] [drm:i915_pages_create_for_stolen], offset=0x0, size=131072 <7>[2.733514] [drm:i915_gem_context_init], Disabling HW Contexts; old hardware <6>[2.733649] [drm] initialized overlay support <7>[2.733654] [drm:intel_modeset_readout_hw_state], [CRTC:3] hw state readout: disabled <7>[2.733664] [drm:intel_modeset_readout_hw_state], [CRTC:4] hw state readout: enabled <7>[2.733670] [drm:intel_modeset_readout_hw_state], [ENCODER:6:LVDS-6] hw state readout: enabled, pipe B <7>[2.733674] [drm:intel_modeset_readout_hw_state], [ENCODER:10:DAC-10] hw state readout: disabled, pipe A <7>[2.733679] [drm:intel_modeset_readout_hw_state], [ENCODER:12:TV-12] hw state readout: disabled, pipe A <7>[2.733683] [drm:intel_modeset_readout_hw_state], [CONNECTOR:5:LVDS-1] hw state readout: enabled <7>[2.733687] [drm:intel_modeset_readout_hw_state], [CONNECTOR:9:VGA-1] hw state readout: disabled <7>[2.733690] [drm:intel_modeset_readout_hw_state], [CONNECTOR:11:SVIDEO-1] hw state readout: disabled <7>[2.733696] [drm:intel_dump_pipe_config], [CRTC:3][setup_hw_state] config for pipe A <7>[2.733699] [drm:intel_dump_pipe_config], cpu_transcoder: A <7>[2.733702] [drm:intel_dump_pipe_config], pipe bpp: 0, dithering: 0 <7>[2.733705] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 <7>[2.733708] [drm:intel_dump_pipe_config], dp: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 <7>[2.733712] [drm:intel_dump_pipe_config], requested mode: <7>[2.733714] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 <7>[2.733719] [drm:intel_dump_pipe_config], adjusted mode: <7>[2.733721] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 <7>[2.733726] [drm:intel_dump_crtc_timings], crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0 <7>[2.733730] [drm:intel_dump_pipe_config], port clock: 0 <7>[2.733732] [drm:intel_dump_pipe_config], pipe src size: 0x0 <7>[2.733735] [drm:intel_dump_pipe_config], gmch pfit: control: 0x, ratios: 0x, lvds border: 0x <7>[2.733738] [drm:intel_dump_pipe_config], pch pfit: pos: 0x, size: 0x, disabled <7>[2.733741] [drm:intel_dump_pipe_config], ips: 0 <7>[2.733743] [drm:intel_dump_pipe_config], double wide: 0 <7>[2.733747] [drm:intel_sanitize_crtc], [CRTC:4] wrong plane connection detected! <4>[2.733750] [ cut here ] <4>[2.733815] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector+0x42/0x50 [i915]() <5>[2.733818] Modules linked in: i915(F+) ata_generic(F) pata_acpi(F) i2c_algo_bit(F) drm_kms_helper(F) yenta_socket(F+) drm(F) tg3(F) ptp(F) pps_core(F) i2c_core(F) video(F) sunrpc(F) <5>[2.733836] CPU: 0 PID: 173 Comm: systemd-udevd Tainted: GF 3.13.0-0.rc2.1.local1.fc18.i686 #1 <5>[2.733839] Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <5>[2.733842] f54979f4 c09b66d2 f5497a24 c0449b14 c0b541a4 <5>[2.733850] 0
