; jasow...@redhat.com
> Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
>
> On Mon, Sep 21, 2015 at 04:34:56PM +, KY Srinivasan wrote:
> >
> >
> > > -Original Message-
> > > From: Olaf Hering [mailto:o...@aepfle.de]
> >
hat.com
> Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
>
> On Mon, Sep 21, Vitaly Kuznetsov wrote:
>
> > I'd like to see a trace from the hang, it is not obvious to me how it
> > happened and what caused it. (or if you have such hang sce
r.kernel.org; de...@linuxdriverproject.org;
> > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com
> > Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
> >
> > On Sun, Sep 20, Greg KH wrote:
> >
> > > Just use a lock, that's what
hat.com
> Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
>
> On Sun, Sep 20, Greg KH wrote:
>
> > Just use a lock, that's what it is there for.
>
> How would that help? It might help because it enforces ordering. But
> that requires that all three ut
Olaf Hering writes:
> On Mon, Sep 21, Vitaly Kuznetsov wrote:
>
>> I'd like to see a trace from the hang, it is not obvious to me how it
>> happened and what caused it. (or if you have such hang scenario in your
>> head, can you please reveal it?)
>
> There is no trace. I think
On Mon, Sep 21, Vitaly Kuznetsov wrote:
> I'd like to see a trace from the hang, it is not obvious to me how it
> happened and what caused it. (or if you have such hang scenario in your
> head, can you please reveal it?)
There is no trace. I think fcopy_respond_to_host notifies the host,
which
Olaf Hering writes:
> On Sun, Sep 20, Greg KH wrote:
>
>> Just use a lock, that's what it is there for.
>
> How would that help? It might help because it enforces ordering. But
> that requires that all three utils get refactored to deal with the
> introduced locking. I will let KY comment on
On Sun, Sep 20, Greg KH wrote:
> Just use a lock, that's what it is there for.
How would that help? It might help because it enforces ordering. But
that requires that all three utils get refactored to deal with the
introduced locking. I will let KY comment on this.
The issue I see with fcopy is
On Sun, Sep 20, Greg KH wrote:
> Just use a lock, that's what it is there for.
How would that help? It might help because it enforces ordering. But
that requires that all three utils get refactored to deal with the
introduced locking. I will let KY comment on this.
The issue I see with fcopy is
Olaf Hering writes:
> On Sun, Sep 20, Greg KH wrote:
>
>> Just use a lock, that's what it is there for.
>
> How would that help? It might help because it enforces ordering. But
> that requires that all three utils get refactored to deal with the
> introduced locking. I will let
Olaf Hering writes:
> On Mon, Sep 21, Vitaly Kuznetsov wrote:
>
>> I'd like to see a trace from the hang, it is not obvious to me how it
>> happened and what caused it. (or if you have such hang scenario in your
>> head, can you please reveal it?)
>
> There is no trace. I think
g;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com
> Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
>
> On Sun, Sep 20, Greg KH wrote:
>
> > Just use a lock, that's what it is there for.
>
> How would that help? It might help because
...@linuxfoundation.org>
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com
> > Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
> >
> > On Sun, Sep 20, Greg K
org; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com
> Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
>
> On Mon, Sep 21, 2015 at 04:34:56PM +, KY Srinivasan wrote:
> >
> >
> > > -Original Message-
> > > From: Ol
On Mon, Sep 21, Vitaly Kuznetsov wrote:
> I'd like to see a trace from the hang, it is not obvious to me how it
> happened and what caused it. (or if you have such hang scenario in your
> head, can you please reveal it?)
There is no trace. I think fcopy_respond_to_host notifies the host,
which
; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; jasow...@redhat.com
> Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
>
> On Mon, Sep 21, Vitaly Kuznetsov wrote:
>
> > I'd like to see a trace from the hang, it is not obvious to m
On Tue, Sep 15, 2015 at 05:37:51PM -0700, K. Y. Srinivasan wrote:
> From: Olaf Hering
>
> The callbacks in kvp, vss and fcopy code are called both from the main thread
> as well as from interrupt context. If a state change is done by the main
> thread it is not immediately seen by the interrupt.
On Tue, Sep 15, 2015 at 05:37:51PM -0700, K. Y. Srinivasan wrote:
> From: Olaf Hering
>
> The callbacks in kvp, vss and fcopy code are called both from the main thread
> as well as from interrupt context. If a state change is done by the main
> thread it is not immediately seen
From: Olaf Hering
The callbacks in kvp, vss and fcopy code are called both from the main thread
as well as from interrupt context. If a state change is done by the main
thread it is not immediately seen by the interrupt. As a result the
state machine gets out of sync.
Force propagation of state
From: Olaf Hering
The callbacks in kvp, vss and fcopy code are called both from the main thread
as well as from interrupt context. If a state change is done by the main
thread it is not immediately seen by the interrupt. As a result the
state machine gets out of sync.
Force
20 matches
Mail list logo