On Sat, Nov 9, 2013 at 12:17 PM, <email address hidden> wrote:
> --- Comment #13 from Chris Wilson <email address hidden> ---
> (In reply to comment #12)
>> I wonder a bit though who's hogging the kms lock - we chase an awful lot of
>> pointers to get at it, so if someone's corrupting this I expect we'd blow
>> up. And lockdep shouldn't be too happy about it either. Confusing.
>
> My theory is that the work item is being called twice. Crazy, huh? But since we
> seem to be very cavalier in scheduling the work even if it is already queued, I
> think it is reasonable to assume that we shoot ourselves in the foot.
The work item should check whether it's run already (or whether we
killed the vdd synchronously), so double-scheduling shouldn't be
harmful. If that isn't, we have a big bug.
On Sat, Nov 9, 2013 at 12:17 PM, <email address hidden> wrote:
> --- Comment #13 from Chris Wilson <email address hidden> ---
> (In reply to comment #12)
>> I wonder a bit though who's hogging the kms lock - we chase an awful lot of
>> pointers to get at it, so if someone's corrupting this I expect we'd blow
>> up. And lockdep shouldn't be too happy about it either. Confusing.
>
> My theory is that the work item is being called twice. Crazy, huh? But since we
> seem to be very cavalier in scheduling the work even if it is already queued, I
> think it is reasonable to assume that we shoot ourselves in the foot.
The work item should check whether it's run already (or whether we
killed the vdd synchronously), so double-scheduling shouldn't be
harmful. If that isn't, we have a big bug.