Apologies all. Nic and I did not realise that an internal email had been
cross-posted to a public mail list (let alone one with strict email formatting
rules!), and were having a hard time understanding the context for the emails
we were receiving.
I have a certain amount of experience of
s a reason Linux is the platform of choice for scalability.
>
> Regards,
> Peter Hurley
>
>> -----Original Message-
>> From: Michael Matz [mailto:m...@suse.de]
>> Sent: 04 May 2015 13:24
>> To: Peter Hurley
>> Cc: NeilBrown; Nic Percival; Greg Kroah
A way of giving context.
This message has been scanned for malware by Websense. www.websense.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
On 05/05/2015 09:34 AM, Chris Purvis wrote:
> Peter,
>
> So is calling tcflush() a solution here?
>
> Regards,
> Chris
What is with the top-posting?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
son Linux is the platform of choice for scalability.
>
> Regards,
> Peter Hurley
>
>> -----Original Message-
>> From: Michael Matz [mailto:m...@suse.de]
>> Sent: 04 May 2015 13:24
>> To: Peter Hurley
>> Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jir
-Original Message-
From: Peter Hurley [mailto:pe...@hurleysoftware.com]
Sent: 05 May 2015 12:19
To: Nic Percival; Michael Matz
Cc: NeilBrown; Greg Kroah-Hartman; Jiri Slaby; linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
'no' when
alability.
Regards,
Peter Hurley
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 04 May 2015 13:24
> To: Peter Hurley
> Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH bisected
: Michael Matz [mailto:m...@suse.de]
Sent: 04 May 2015 13:24
To: Peter Hurley
Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
'no' when it should say 'yes'
Hi,
On Fri, 1 May 2015
-Original Message-
From: Michael Matz [mailto:m...@suse.de]
Sent: 04 May 2015 13:24
To: Peter Hurley
Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
'no' when it should
A way of giving context.
This message has been scanned for malware by Websense. www.websense.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
On 05/05/2015 09:34 AM, Chris Purvis wrote:
Peter,
So is calling tcflush() a solution here?
Regards,
Chris
What is with the top-posting?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Apologies all. Nic and I did not realise that an internal email had been
cross-posted to a public mail list (let alone one with strict email formatting
rules!), and were having a hard time understanding the context for the emails
we were receiving.
I have a certain amount of experience of
[mailto:pe...@hurleysoftware.com]
Sent: 05 May 2015 14:29
To: Nic Percival; Michael Matz; Kevin Fletcher; Paul Matthews; Chris Purvis
Cc: NeilBrown; Greg Kroah-Hartman; Jiri Slaby; linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
'no' when it should
-
From: Michael Matz [mailto:m...@suse.de]
Sent: 04 May 2015 13:24
To: Peter Hurley
Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
'no' when it should say 'yes'
Hi
: Michael Matz [mailto:m...@suse.de]
Sent: 04 May 2015 13:24
To: Peter Hurley
Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
'no' when it should say 'yes'
Hi,
On Fri, 1 May 2015
Matz [mailto:m...@suse.de]
Sent: 04 May 2015 13:24
To: Peter Hurley
Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says
'no' when it should say 'yes'
Hi,
On Fri, 1 May 2015
On 05/04/2015 12:56 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 4 May 2015, Peter Hurley wrote:
>
>> I think it would be a shame if ptrace() usage forced a whole class of
>> i/o to be synchronous.
>
> I think Neils patch doesn't do that, does it?
Yes. Non-blocking i/o would now have to wait
Hi,
On Mon, 4 May 2015, Peter Hurley wrote:
> I think it would be a shame if ptrace() usage forced a whole class of
> i/o to be synchronous.
I think Neils patch doesn't do that, does it? If it has an indication
that in fact some data must be there but isn't it pulls it, otherwise it's
the
On 05/04/2015 08:24 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 1 May 2015, Peter Hurley wrote:
>
>> I don't think this a real bug, in the sense that pty i/o is not
>> synchronous, in the same way that tty i/o is not synchronous.
>
> Here's what I wrote internally about my speculations about
Hi,
On Fri, 1 May 2015, Peter Hurley wrote:
> I don't think this a real bug, in the sense that pty i/o is not
> synchronous, in the same way that tty i/o is not synchronous.
Here's what I wrote internally about my speculations about this being a
bug or not:
> > I also never hit it with pipes
Hi,
On Fri, 1 May 2015, Peter Hurley wrote:
I don't think this a real bug, in the sense that pty i/o is not
synchronous, in the same way that tty i/o is not synchronous.
Here's what I wrote internally about my speculations about this being a
bug or not:
I also never hit it with pipes
On 05/04/2015 08:24 AM, Michael Matz wrote:
Hi,
On Fri, 1 May 2015, Peter Hurley wrote:
I don't think this a real bug, in the sense that pty i/o is not
synchronous, in the same way that tty i/o is not synchronous.
Here's what I wrote internally about my speculations about this being a
Hi,
On Mon, 4 May 2015, Peter Hurley wrote:
I think it would be a shame if ptrace() usage forced a whole class of
i/o to be synchronous.
I think Neils patch doesn't do that, does it? If it has an indication
that in fact some data must be there but isn't it pulls it, otherwise it's
the
On 05/04/2015 12:56 PM, Michael Matz wrote:
Hi,
On Mon, 4 May 2015, Peter Hurley wrote:
I think it would be a shame if ptrace() usage forced a whole class of
i/o to be synchronous.
I think Neils patch doesn't do that, does it?
Yes. Non-blocking i/o would now have to wait until the
Hi Neil,
On 05/01/2015 02:20 AM, NeilBrown wrote:
>
> Hi Peter,
> I recently had a report of a regression in 3.12. I bisected it down to your
> patch
> f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
>
> Sometimes a poll on a master-pty will report there is nothing to
Hi Peter,
I recently had a report of a regression in 3.12. I bisected it down to your
patch
f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
Sometimes a poll on a master-pty will report there is nothing to read after
the slave has written something.
As test program is
Hi Neil,
On 05/01/2015 02:20 AM, NeilBrown wrote:
Hi Peter,
I recently had a report of a regression in 3.12. I bisected it down to your
patch
f95499c3030f (n_tty: Don't wait for buffer work in read() loop)
Sometimes a poll on a master-pty will report there is nothing to read after
Hi Peter,
I recently had a report of a regression in 3.12. I bisected it down to your
patch
f95499c3030f (n_tty: Don't wait for buffer work in read() loop)
Sometimes a poll on a master-pty will report there is nothing to read after
the slave has written something.
As test program is
28 matches
Mail list logo
