Peter Hurley wrote:
> On 10/09/2015 01:28 PM, Peter Hurley wrote:
>> Tatsukawa-san,
>>
>> I would still like to root-cause the reported stall; is the reported
>> stall resolved if smp_mb() is added before the waitqueue_active()
>> in __receive_buf()?
>
> Nevermind, I see it now.
>
> The store to c
On 10/09/2015 01:28 PM, Peter Hurley wrote:
> Tatsukawa-san,
>
> I would still like to root-cause the reported stall; is the reported
> stall resolved if smp_mb() is added before the waitqueue_active()
> in __receive_buf()?
Nevermind, I see it now.
The store to commit_head is deferred until afte
On 10/02/2015 04:27 AM, Kosuke Tatsukawa wrote:
> My colleague ran into a program stall on a x86_64 server, where
> n_tty_read() was waiting for data even if there was data in the buffer
> in the pty. kernel stack for the stuck process looks like below.
> #0 [88303d107b58] __schedule at f
On 10/02/2015 04:27 AM, Kosuke Tatsukawa wrote:
> My colleague ran into a program stall on a x86_64 server, where
> n_tty_read() was waiting for data even if there was data in the buffer
> in the pty. kernel stack for the stuck process looks like below.
> #0 [88303d107b58] __schedule at f
My colleague ran into a program stall on a x86_64 server, where
n_tty_read() was waiting for data even if there was data in the buffer
in the pty. kernel stack for the stuck process looks like below.
#0 [88303d107b58] __schedule at 815c4b20
#1 [88303d107bd0] schedule at 8
5 matches
Mail list logo
