Hi!
> This patch causes lockups in firefox. They appear like non-fatal hangs
> of the webpage contents, "fixable" with alt-tab or a background system
> load. I have verified that reverting the commit 754a254427 on top of
> current Linus tree fixes the problem.
This is still broken in v5.2-rc3.
Hi!
This patch causes lockups in firefox. They appear like non-fatal hangs
of the webpage contents, "fixable" with alt-tab or a background system
load. I have verified that reverting the commit 754a254427 on top of
current Linus tree fixes the problem.
Quoting Ville Syrjälä (2019-03-22 14:28:37)
> On Thu, Mar 21, 2019 at 04:19:08PM +, Chris Wilson wrote:
> > If we are already in the desired write domain of a set-domain ioctl,
> > then there is nothing for us to do and we can quickly return back to
> > userspace, avoiding any lock contention.
On Thu, Mar 21, 2019 at 04:19:08PM +, Chris Wilson wrote:
> If we are already in the desired write domain of a set-domain ioctl,
> then there is nothing for us to do and we can quickly return back to
> userspace, avoiding any lock contention. By recognising that the
> write_domain is always a s
On Thu, 21 Mar 2019 at 13:43, Chris Wilson wrote:
>
> If we are already in the desired write domain of a set-domain ioctl,
> then there is nothing for us to do and we can quickly return back to
> userspace, avoiding any lock contention. By recognising that the
> write_domain is always a subset of
If we are already in the desired write domain of a set-domain ioctl,
then there is nothing for us to do and we can quickly return back to
userspace, avoiding any lock contention. By recognising that the
write_domain is always a subset of the read_domains, and excluding the
no-op case of requiring 0
If we are already in the desired write domain of a set-domain ioctl,
then there is nothing for us to do and we can quickly return back to
userspace, avoiding any lock contention. By recognising that the
write_domain is always a subset of the read_domains, and excluding the
no-op case of requiring 0
