On Fri 2020-04-03 15:00:31, Pavel Machek wrote:
> Hi!
>
> 7dc8f1143778a35b190f9413f228b3cf28f67f8d
>
> drm/i915/gem: Drop relocation slowpath
>
> Since the relocations are no longer performed under a global
> struct_mutex, or any other lock, that is also held by pagefault handlers,
> we can relax and allow our fast path to take a fault. As we no longer
> need to abort the fast path for lock avoidance, we no longer need the
> slow path handling at all.
>
> causes regression on thinkpad x220: instead of starting X, I'm looking
> at blinking cursor.
>
> Reverting the patch on too of 919dce24701f7b3 fixes things for me.
I have received no feedback from patch authors, and I believe we don't
want to break boot in -rc1 on Intel hardware... so the commit should
be simply reverted.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoting Pavel Machek (2020-04-07 08:20:47)
>
> On Fri 2020-04-03 15:00:31, Pavel Machek wrote:
> > Hi!
> >
> > 7dc8f1143778a35b190f9413f228b3cf28f67f8d
> >
> > drm/i915/gem: Drop relocation slowpath
> >
> > Since the relocations are no longer performed under a global
> > struct_mutex, or any other lock, that is also held by pagefault handlers,
> > we can relax and allow our fast path to take a fault. As we no longer
> > need to abort the fast path for lock avoidance, we no longer need the
> > slow path handling at all.
> >
> > causes regression on thinkpad x220: instead of starting X, I'm looking
> > at blinking cursor.
> >
> > Reverting the patch on too of 919dce24701f7b3 fixes things for me.
>
> I have received no feedback from patch authors, and I believe we don't
> want to break boot in -rc1 on Intel hardware... so the commit should
> be simply reverted.
Beyond the fix already submitted?
-Chris
Hi!
> > > 7dc8f1143778a35b190f9413f228b3cf28f67f8d
> > >
> > > drm/i915/gem: Drop relocation slowpath
> > >
> > > Since the relocations are no longer performed under a global
> > > struct_mutex, or any other lock, that is also held by pagefault handlers,
> > > we can relax and allow our fast path to take a fault. As we no longer
> > > need to abort the fast path for lock avoidance, we no longer need the
> > > slow path handling at all.
> > >
> > > causes regression on thinkpad x220: instead of starting X, I'm looking
> > > at blinking cursor.
> > >
> > > Reverting the patch on too of 919dce24701f7b3 fixes things for me.
> >
> > I have received no feedback from patch authors, and I believe we don't
> > want to break boot in -rc1 on Intel hardware... so the commit should
> > be simply reverted.
>
> Beyond the fix already submitted?
I did not get that one, can I have a pointer?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Apr 7, 2020 at 12:48 AM Pavel Machek <[email protected]> wrote:
>
> >
> > Beyond the fix already submitted?
>
> I did not get that one, can I have a pointer?
What's the status of this one?
I'm assuming the fix is commit 721017cf4bd8 ("drm/i915/gem: Ignore
readonly failures when updating relics"), but didn't see a reply to
the query or a confirmation of things working..
Btw, Chris, that __put_user() not testing the error should at least
have a comment. We don't have a working "__must_check" for those
things (because they are subtle macros, not functions), but if we did,
we'd get a compiler warning for not checking the error value.
Linus
Hi!
> > > Beyond the fix already submitted?
> >
> > I did not get that one, can I have a pointer?
>
> What's the status of this one?
I tried updating my kernel on April 3, that one did not work, but it
did not include 721017cf4bd8.
> I'm assuming the fix is commit 721017cf4bd8 ("drm/i915/gem: Ignore
> readonly failures when updating relics"), but didn't see a reply to
> the query or a confirmation of things working..
I pulled latest tree from Linus, and this one has 721017cf4bd8. Let my
try to revert my revert, and test... yes, this one seems okay.
Something changed in the X, now it seems that only one monitor is used
for login, not both... but it now works.
Best regards,
Pavel
PS: Hmm. This is not helpful. I guess this is "N".
*
* VDPA drivers
*
VDPA drivers (VDPA_MENU) [N/y/?] (NEW) ?
There is no help available for this option.
Symbol: VDPA_MENU [=n]
Type : bool
Defined at drivers/vdpa/Kconfig:9
Prompt: VDPA drivers
Location:
-> Device Drivers
*
* VHOST drivers
*
VHOST drivers (VHOST_MENU) [Y/n/?] (NEW) ?
There is no help available for this option.
Symbol: VHOST_MENU [=y]
Type : bool
Defined at drivers/vhost/Kconfig:21
Prompt: VHOST drivers
Location:
-> Device Drivers
> Btw, Chris, that __put_user() not testing the error should at least
> have a comment. We don't have a working "__must_check" for those
> things (because they are subtle macros, not functions), but if we did,
> we'd get a compiler warning for not checking the error value.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html