From: Jani Nikula <jani.nikula@linux.intel.com>
To: alexander.levin@verizon.com, Tuncer Ayaz <tuncer.ayaz@gmail.com>
Cc: "airlied@linux.ie" <airlied@linux.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"daniel.vetter@intel.com" <daniel.vetter@intel.com>
Subject: Re: 4.1 EOL
Date: Tue, 14 Nov 2017 10:46:29 +0200 [thread overview]
Message-ID: <87lgj9p7ru.fsf@intel.com> (raw)
In-Reply-To: <20171113210000.ixivmcjy2ianuu7t@sasha-lappy>
Tuncer, where's your bug report? Can't find one. Please file your bug at
the fdo bugzilla.
Thanks,
Jani.
On Mon, 13 Nov 2017, alexander.levin@verizon.com wrote:
> I've cc'ed some folks in hopes to get this resolved upstream.
>
> Either way, 4.1's EoL was previously moved to about 6 months from now,
> so hopefully we'll have more than enough time to get this resolved.
>
> On Sat, Nov 11, 2017 at 10:13:55PM +0000, Tuncer Ayaz wrote:
>>The predicament I'm in on my machines is that ever since drm-intel has
>>implemented atomic modesetting, there's a list regressions caused by
>>those fundamental architecture changes and the code churn it implied.
>>This means 4.1 is (from what I can tell) the last kernel before atomic
>>modesetting was added and the only kernel free of all those issues
>>which necessitate trying out various combinations of flags on the
>>kernel cmdline.
>>
>>For instance, right now I'm trying 4.13.12 with these flags:
>>video=SVIDEO-1:d
>>i915.semaphores=1
>>i915.enable_rc6=0
>>i915.enable_psr=0
>>intel_iommu=igfx_off
>>
>>PS: I'm kinda confused how anyone uses DMAR with VT-d when it's known
>>to be buggy.
>>
>>The flags seem to decrease the chances of provoking the bugs, but after a
>>day of running Xorg, it's possible to still hit the RCS0 GPU hangs.
>>
>>If you don't pass video=SVIDEO-1:d, then atomic's flip_done times out
>>on boot or exit to VT console. It's good that other people have the same
>>issues and have been following the bugzilla tickets, and con confirm
>>the results.
>>
>>I'm kinda glad I don't have a machine that's newer than Sandybridge
>>since that means I can use 4.1, though it's not a long-term solution,
>>and the plan is for the reported bugzilla tickets to be resolved at
>>some point, or me switching away from Intel GPUs, which might be
>>doable if I save money and get an AMD APU laptop next summer and
>>switch my desktop to a discrete GPU.
>>
>>For example:
>>https://bugs.freedesktop.org/show_bug.cgi?id=101237
>>https://bugs.freedesktop.org/show_bug.cgi?id=103076
>>https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
>>https://bugs.archlinux.org/task/51703
>>
>>So, since 4.4, 4.9 and 4.12, drm-tip are still regressive,
>>I wanted to ask if you considered pushing back 4.1's EOL.
>>
>>Given a look at bugzilla, I have the impression that those issues will
>>need at least another year before they're fixed, since most of them
>>have been sitting there for many, many months. I suspect the Intel DRM
>>team doesn't have the bandwidth to address the issues in a timely
>>fashion while still adding upbringing for new GPUs and features
>>(fences, etc.).
>>
>>The generic modesetting DDX and Wayland are less susceptible to the
>>GPU hangs, but can be made to provoke it if tried long enough.
>>However, the modesetting DDX tears heavily and is about to gain atomic
>>modesetting in the next Xorg release, so will suffer from the same
>>easy GPU hang likelihood.
>>
>>Prior to SandyBridge there was zero tearing but beginning with
>>SandyBridge xf86-video-intel's TearFree=TRUE is the only reliable way
>>to fix Xorg tearing.
>>
>>I do appreciate you maintaining 4.1 so far and hate to admit that I'm
>>reliant on it on more than two machines, before and after Sandybridge,
>>exluding those machines which need a newer kernel. I also understand
>>how much work this is and since I'm not using Linux professionally for
>>a product, I can't offer compensation for your time. I can only offer
>>to collect and point you at a list of DRM bugs for validation of my
>>claims.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: alexander.levin@verizon.com, Tuncer Ayaz <tuncer.ayaz@gmail.com>
Cc: "daniel.vetter\@intel.com" <daniel.vetter@intel.com>,
"seanpaul\@chromium.org" <seanpaul@chromium.org>,
"airlied\@linux.ie" <airlied@linux.ie>,
"dri-devel\@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable\@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: 4.1 EOL
Date: Tue, 14 Nov 2017 10:46:29 +0200 [thread overview]
Message-ID: <87lgj9p7ru.fsf@intel.com> (raw)
In-Reply-To: <20171113210000.ixivmcjy2ianuu7t@sasha-lappy>
Tuncer, where's your bug report? Can't find one. Please file your bug at
the fdo bugzilla.
Thanks,
Jani.
On Mon, 13 Nov 2017, alexander.levin@verizon.com wrote:
> I've cc'ed some folks in hopes to get this resolved upstream.
>
> Either way, 4.1's EoL was previously moved to about 6 months from now,
> so hopefully we'll have more than enough time to get this resolved.
>
> On Sat, Nov 11, 2017 at 10:13:55PM +0000, Tuncer Ayaz wrote:
>>The predicament I'm in on my machines is that ever since drm-intel has
>>implemented atomic modesetting, there's a list regressions caused by
>>those fundamental architecture changes and the code churn it implied.
>>This means 4.1 is (from what I can tell) the last kernel before atomic
>>modesetting was added and the only kernel free of all those issues
>>which necessitate trying out various combinations of flags on the
>>kernel cmdline.
>>
>>For instance, right now I'm trying 4.13.12 with these flags:
>>video=SVIDEO-1:d
>>i915.semaphores=1
>>i915.enable_rc6=0
>>i915.enable_psr=0
>>intel_iommu=igfx_off
>>
>>PS: I'm kinda confused how anyone uses DMAR with VT-d when it's known
>>to be buggy.
>>
>>The flags seem to decrease the chances of provoking the bugs, but after a
>>day of running Xorg, it's possible to still hit the RCS0 GPU hangs.
>>
>>If you don't pass video=SVIDEO-1:d, then atomic's flip_done times out
>>on boot or exit to VT console. It's good that other people have the same
>>issues and have been following the bugzilla tickets, and con confirm
>>the results.
>>
>>I'm kinda glad I don't have a machine that's newer than Sandybridge
>>since that means I can use 4.1, though it's not a long-term solution,
>>and the plan is for the reported bugzilla tickets to be resolved at
>>some point, or me switching away from Intel GPUs, which might be
>>doable if I save money and get an AMD APU laptop next summer and
>>switch my desktop to a discrete GPU.
>>
>>For example:
>>https://bugs.freedesktop.org/show_bug.cgi?id=101237
>>https://bugs.freedesktop.org/show_bug.cgi?id=103076
>>https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
>>https://bugs.archlinux.org/task/51703
>>
>>So, since 4.4, 4.9 and 4.12, drm-tip are still regressive,
>>I wanted to ask if you considered pushing back 4.1's EOL.
>>
>>Given a look at bugzilla, I have the impression that those issues will
>>need at least another year before they're fixed, since most of them
>>have been sitting there for many, many months. I suspect the Intel DRM
>>team doesn't have the bandwidth to address the issues in a timely
>>fashion while still adding upbringing for new GPUs and features
>>(fences, etc.).
>>
>>The generic modesetting DDX and Wayland are less susceptible to the
>>GPU hangs, but can be made to provoke it if tried long enough.
>>However, the modesetting DDX tears heavily and is about to gain atomic
>>modesetting in the next Xorg release, so will suffer from the same
>>easy GPU hang likelihood.
>>
>>Prior to SandyBridge there was zero tearing but beginning with
>>SandyBridge xf86-video-intel's TearFree=TRUE is the only reliable way
>>to fix Xorg tearing.
>>
>>I do appreciate you maintaining 4.1 so far and hate to admit that I'm
>>reliant on it on more than two machines, before and after Sandybridge,
>>exluding those machines which need a newer kernel. I also understand
>>how much work this is and since I'm not using Linux professionally for
>>a product, I can't offer compensation for your time. I can only offer
>>to collect and point you at a list of DRM bugs for validation of my
>>claims.
--
Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2017-11-14 8:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOvwQ4i_VTLg_P-mCTesTvUENYmtix1MfbmFQ=WTC6UUT-DroA@mail.gmail.com>
[not found] ` <20171111200025.hz6zbcqy7uacqd2s@sasha-lappy>
[not found] ` <CAOvwQ4hsy1CSKGCwm_Y+j-VGpmXMAF_vhg+WnifphhxVd3ur8A@mail.gmail.com>
2017-11-13 21:00 ` 4.1 EOL alexander.levin
2017-11-14 8:46 ` Jani Nikula [this message]
2017-11-14 8:46 ` Jani Nikula
2017-11-14 21:41 ` Tuncer Ayaz
2017-11-15 10:04 ` Jani Nikula
2017-11-15 10:04 ` Jani Nikula
2017-11-15 17:00 ` Tuncer Ayaz
2017-11-16 9:13 ` Jani Nikula
2017-11-16 9:13 ` Jani Nikula
2017-11-17 7:42 ` Tuncer Ayaz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgj9p7ru.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@linux.ie \
--cc=alexander.levin@verizon.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tuncer.ayaz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.