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
; Huge thanks again
You're welcome.
Paul Bolle
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
> &g
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
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
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 appl
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
ks 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
hat 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
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
ce).
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
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
27;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
ch 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:/
cy. 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.
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_maintain
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 spa
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
ic 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
. 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
[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 betw
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
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 po
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 lis
cially 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
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 ip
e 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 yoursel
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
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
> >
> >&
nel.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
valent 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"
s.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
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 t
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
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
aive 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
e 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
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
> > Kco
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
ing 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,
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/
gt;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@
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
e 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 m
[] ? __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
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
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
>
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
o, 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
* "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,
>
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 comm
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
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
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 th
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
he
> 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 li
fff : 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
ff000
e 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-
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/0x
> 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 W
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
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
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 mak
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 tha
64 matches
Mail list logo
