Displaying 8 results from an estimated 8 matches for "atomic_sleep".
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sat, Jun 16, 2018 at 05:39:11PM +0200, Mike Galbraith wrote:
> Greetings,
>
> Running a kernel with ATOMIC_SLEEP enabled in one of my VMs, I met the
> splat below. I tracked it back to 4.14-stable, and bisected it there.
Why does your virtual machine use a drm driver? Ah, it's a driver for
virtual gpu, nice.
And if you revert that patch, does everything work again?
> # first bad commit: [848dd9...
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sat, Jun 16, 2018 at 05:39:11PM +0200, Mike Galbraith wrote:
> Greetings,
>
> Running a kernel with ATOMIC_SLEEP enabled in one of my VMs, I met the
> splat below. I tracked it back to 4.14-stable, and bisected it there.
Why does your virtual machine use a drm driver? Ah, it's a driver for
virtual gpu, nice.
And if you revert that patch, does everything work again?
> # first bad commit: [848dd9...
2018 Jun 17
0
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote:
>
> And if you revert that patch, does everything work again?
Yes.
-Mike
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote:
> On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote:
> >
> > And if you revert that patch, does everything work again?
>
> Yes.
Great, Dave, care to revert this in 4.18 so I can queue up that revert
in older kernels as well?
thanks,
greg k-h
2018 Jun 18
0
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On 17 June 2018 at 21:02, Greg KH <gregkh at linuxfoundation.org> wrote:
> On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote:
>> On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote:
>> >
>> > And if you revert that patch, does everything work again?
>>
>> Yes.
>
> Great, Dave, care to revert this in 4.18 so I can queue up that revert
2018 Jun 17
2
v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote:
> On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote:
> >
> > And if you revert that patch, does everything work again?
>
> Yes.
Great, Dave, care to revert this in 4.18 so I can queue up that revert
in older kernels as well?
thanks,
greg k-h
2020 Oct 24
0
kvm+nouveau induced lockdep gripe
...ble unsafe locking scenario:
[ 30.457375] CPU0
[ 30.457378] ----
[ 30.457381] lock(&mgr->vm_lock);
[ 30.457386] <Interrupt>
[ 30.457389] lock(&mgr->vm_lock);
[ 30.457394]
*** DEADLOCK ***
<snips 999 lockdep lines and zillion ATOMIC_SLEEP gripes>
2020 Oct 24
1
kvm+nouveau induced lockdep gripe
On Fri, 23 Oct 2020 14:07:13 +0200 Mike Galbraith wrote:
> On Fri, 2020-10-23 at 11:01 +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote:
> > > I've only as yet seen nouveau lockdep gripage when firing up one of my
> > > full distro KVM's.
> >
> > Could you please check !RT with the `threadirqs'