On Fri, Mar 16, 2018 at 12:26 AM Byungchul Park wrote:
>
> On 3/15/2018 9:41 PM, Peter Zijlstra wrote:
> > On Thu, Mar 15, 2018 at 11:31:57AM +0100, Daniel Vetter wrote:
> >> Is there any progress on getting cross-release enabled again?
> >
> > Not yet, I'm still fighting the meltdown/spectre indu
On 3/15/2018 9:41 PM, Peter Zijlstra wrote:
On Thu, Mar 15, 2018 at 11:31:57AM +0100, Daniel Vetter wrote:
Is there any progress on getting cross-release enabled again?
Not yet, I'm still fighting the meltdown/spectre induced backlog.
We'll get to it eventually.
Please let me know when you
On Thu, Mar 15, 2018 at 11:31:57AM +0100, Daniel Vetter wrote:
> Is there any progress on getting cross-release enabled again?
Not yet, I'm still fighting the meltdown/spectre induced backlog.
We'll get to it eventually.
___
dri-devel mailing list
dri-d
On Wed, Dec 20, 2017 at 2:14 AM, Byungchul Park wrote:
> On 12/19/2017 6:59 PM, Daniel Vetter wrote:
>>
>> On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:
>>>
>>> On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
This didn't seem to have made it into -rc4. Anyt
On 12/19/2017 6:59 PM, Daniel Vetter wrote:
On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:
On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
This didn't seem to have made it into -rc4. Anything needed to get it
going?
Do you actually see the problem in -rc4?
Because w
On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:
> On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
> >
> > This didn't seem to have made it into -rc4. Anything needed to get it
> > going?
>
> Do you actually see the problem in -rc4?
>
> Because we ended up removing the cros
On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
>
> This didn't seem to have made it into -rc4. Anything needed to get it
> going?
Do you actually see the problem in -rc4?
Because we ended up removing the cross-release checking due to other
developers complaining. It seemed to need a lot
On Mon, Dec 11, 2017 at 10:19:28AM +0100, Daniel Vetter wrote:
> On Fri, Dec 08, 2017 at 11:54:19AM +0100, Peter Zijlstra wrote:
> > On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> > > Since -rc1 we're hitting a bunch of lockdep splats using the new
> > > cross-release stuff around
On Fri, Dec 08, 2017 at 11:54:19AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> > Since -rc1 we're hitting a bunch of lockdep splats using the new
> > cross-release stuff around the 2 kthread completions. In all cases
> > they are because totally i
On Fri, Dec 08, 2017 at 05:36:28PM +0100, Daniel Vetter wrote:
> Aside: Could/should we take some fake lockdep locks around these
> callbacks, since not all drivers call them from a hardirq context? Just to
> validate that everyone follows the contract.
What I typically do is use local_irq_save/r
On Fri, Dec 08, 2017 at 11:14:16AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 07, 2017 at 09:56:57PM +0100, Daniel Vetter wrote:
> > On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote:
>
> > > Is what it says I suppose. Now I don't know enough about that i915 code
> > > to say if that
On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> Since -rc1 we're hitting a bunch of lockdep splats using the new
> cross-release stuff around the 2 kthread completions. In all cases
> they are because totally independent uses of kthread are mixed up by
> lockdep into the same locki
On Thu, Dec 07, 2017 at 09:56:57PM +0100, Daniel Vetter wrote:
> On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote:
> > Is what it says I suppose. Now I don't know enough about that i915 code
> > to say if that breadcrumbs_signal thread can ever trigger a fault or
> > not. I got prope
On Thu, Dec 07, 2017 at 08:57:09PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 07, 2017 at 03:58:28PM +0100, Daniel Vetter wrote:
>
> > [ 85.069417] gem_exec_captur/2810 is trying to acquire lock:
> > [ 85.069419] ((completion)&self->parked){+.+.}, at: []
> > kthread_park+0x3d/0x50
> > [ 85
On Thu, Dec 07, 2017 at 03:58:28PM +0100, Daniel Vetter wrote:
> [ 85.069417] gem_exec_captur/2810 is trying to acquire lock:
> [ 85.069419] ((completion)&self->parked){+.+.}, at: []
> kthread_park+0x3d/0x50
> [ 85.069426]
>but task is already holding lock:
> [ 85.069428
On Thu, Dec 07, 2017 at 01:22:56PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> > Since -rc1 we're hitting a bunch of lockdep splats using the new
> > cross-release stuff around the 2 kthread completions. In all cases
> > they are because totally i
On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> Since -rc1 we're hitting a bunch of lockdep splats using the new
> cross-release stuff around the 2 kthread completions. In all cases
> they are because totally independent uses of kthread are mixed up by
> lockdep into the same locki
Since -rc1 we're hitting a bunch of lockdep splats using the new
cross-release stuff around the 2 kthread completions. In all cases
they are because totally independent uses of kthread are mixed up by
lockdep into the same locking class, creating artificial deadlocks.
Fix this by converting kthrea
18 matches
Mail list logo
