Hi,
If you run perf top on 3.14 but you force --stdio mode, perf top
goes crazy and constantly refreshes the output.
It does that with many older versions of the perf as well on 3.14.
It runs fine with newt mode.
Works fine with my 3.11 kernel. So something must be broken
with 3.14.
Can you reproduce the problem as well?
On Wed, Feb 5, 2014 at 10:25 PM, Stephane Eranian <[email protected]> wrote:
> Hi,
>
> If you run perf top on 3.14 but you force --stdio mode, perf top
> goes crazy and constantly refreshes the output.
>
> It does that with many older versions of the perf as well on 3.14.
> It runs fine with newt mode.
>
> Works fine with my 3.11 kernel. So something must be broken
> with 3.14.
>
Or more likely, there is something broken in perf which gets exposed
by 3.14.
Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> If you run perf top on 3.14 but you force --stdio mode, perf top
> goes crazy and constantly refreshes the output.
>
> It does that with many older versions of the perf as well on 3.14.
> It runs fine with newt mode.
>
> Works fine with my 3.11 kernel. So something must be broken
> with 3.14.
> Can you reproduce the problem as well?
Not so far, using my perf/urgent branch:
[root@ssdandy ~]# perf --version
perf version 3.13.g1da187
Also it honours --delay, i.e.
# perf top --delay 5 --stdio
it will wait 5 seconds between refreshes, etc.
Checking out v3.14-rc1 now.
- Arnaldo
On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
<[email protected]> wrote:
> Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>> If you run perf top on 3.14 but you force --stdio mode, perf top
>> goes crazy and constantly refreshes the output.
>>
>> It does that with many older versions of the perf as well on 3.14.
>> It runs fine with newt mode.
>>
>> Works fine with my 3.11 kernel. So something must be broken
>> with 3.14.
>
>> Can you reproduce the problem as well?
>
> Not so far, using my perf/urgent branch:
>
I am using tip.git. Or try 3.11, 3.10.
> [root@ssdandy ~]# perf --version
> perf version 3.13.g1da187
>
> Also it honours --delay, i.e.
>
> # perf top --delay 5 --stdio
>
> it will wait 5 seconds between refreshes, etc.
>
> Checking out v3.14-rc1 now.
>
> - Arnaldo
Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
> On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
> <[email protected]> wrote:
> > Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> >> If you run perf top on 3.14 but you force --stdio mode, perf top
> >> goes crazy and constantly refreshes the output.
> >> It does that with many older versions of the perf as well on 3.14.
> >> It runs fine with newt mode.
> >> Works fine with my 3.11 kernel. So something must be broken
> >> with 3.14.
> >> Can you reproduce the problem as well?
> > Not so far, using my perf/urgent branch:
> I am using tip.git. Or try 3.11, 3.10.
Tried torvalds/master, no problem, looking at what the top's screen
refresh thread does we can see:
[root@ssdandy ~]# trace -t 3562 -e \!write
0.000 ( 0.000 ms): ... [continued]: poll()) = 0 Timeout
2031.522 (2002.480 ms): poll(ufds: 0x7fbb91596bb0, nfds: 1, timeout_msecs: 2000 ) = 0 Timeout
4064.346 (2002.456 ms): poll(ufds: 0x7fbb91596bb0, nfds: 1, timeout_msecs: 2000 ) = 0 Timeout
^C[root@ssdandy ~]#
I.e. waiting the default of:
.delay_secs = 2,
2 seconds between refreshes.
Checking out tip.tip, or are you suggesting to try an old perf binary, from
3.11 or 3.10 on top of a newer kernel?
- Arnaldo
Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
> > On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
> > <[email protected]> wrote:
> > > Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> > >> If you run perf top on 3.14 but you force --stdio mode, perf top
> > >> goes crazy and constantly refreshes the output.
>
> > >> It does that with many older versions of the perf as well on 3.14.
> > >> It runs fine with newt mode.
>
> > >> Works fine with my 3.11 kernel. So something must be broken
> > >> with 3.14.
>
> > >> Can you reproduce the problem as well?
>
> > > Not so far, using my perf/urgent branch:
>
> > I am using tip.git. Or try 3.11, 3.10.
But my tests are on top of:
[acme@ssdandy linux]$ uname -r
3.11.4-101.fc18.x86_64
I thought it was a 3.14ish one, building one to try there...
- Arnaldo
On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
<[email protected]> wrote:
> Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
>> > On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
>> > <[email protected]> wrote:
>> > > Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>> > >> If you run perf top on 3.14 but you force --stdio mode, perf top
>> > >> goes crazy and constantly refreshes the output.
>>
>> > >> It does that with many older versions of the perf as well on 3.14.
>> > >> It runs fine with newt mode.
>>
>> > >> Works fine with my 3.11 kernel. So something must be broken
>> > >> with 3.14.
>>
>> > >> Can you reproduce the problem as well?
>>
>> > > Not so far, using my perf/urgent branch:
>>
>> > I am using tip.git. Or try 3.11, 3.10.
>
> But my tests are on top of:
>
> [acme@ssdandy linux]$ uname -r
> 3.11.4-101.fc18.x86_64
>
> I thought it was a 3.14ish one, building one to try there...
>
The kernel must be 3.14-rcX, the tool can be any version.
> - Arnaldo
On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> <[email protected]> wrote:
>> Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
>>> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
>>>> On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
>>>> <[email protected]> wrote:
>>>>> Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>>>>>> If you run perf top on 3.14 but you force --stdio mode, perf top
>>>>>> goes crazy and constantly refreshes the output.
>>>
>>>>>> It does that with many older versions of the perf as well on 3.14.
>>>>>> It runs fine with newt mode.
>>>
>>>>>> Works fine with my 3.11 kernel. So something must be broken
>>>>>> with 3.14.
>>>
>>>>>> Can you reproduce the problem as well?
>>>
>>>>> Not so far, using my perf/urgent branch:
>>>
>>>> I am using tip.git. Or try 3.11, 3.10.
>>
>> But my tests are on top of:
>>
>> [acme@ssdandy linux]$ uname -r
>> 3.11.4-101.fc18.x86_64
>>
>> I thought it was a 3.14ish one, building one to try there...
>>
> The kernel must be 3.14-rcX, the tool can be any version.
I don't have time to do a git bisect, but I can narrow the window to
3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
perf-top --stdio runs fine on the former and shows the problem on the
latter.
David
Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
> On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> >>>>I am using tip.git. Or try 3.11, 3.10.
> >>
> >>But my tests are on top of:
> >>
> >>[acme@ssdandy linux]$ uname -r
> >>3.11.4-101.fc18.x86_64
> >>
> >>I thought it was a 3.14ish one, building one to try there...
> >>
> >The kernel must be 3.14-rcX, the tool can be any version.
>
>
> I don't have time to do a git bisect, but I can narrow the window to
> 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
> perf-top --stdio runs fine on the former and shows the problem on
> the latter.
Humm,
/*
* Either timeout expired or we got an EINTR due to
* SIGWINCH, refresh screen in both cases.
*/
switch (poll(&stdin_poll, 1, delay_msecs)) {
And poll is returning 1:
951.068 ( 0.002 ms): poll(ufds: 0x7ff660befbb0, nfds: 1, timeout_msecs: 2000) = 1
Checking...
- Arnaldo
Em Thu, Feb 06, 2014 at 05:21:31PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
> > On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> > >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> > >>>>I am using tip.git. Or try 3.11, 3.10.
> > >>But my tests are on top of:
> > >>[acme@ssdandy linux]$ uname -r
> > >>3.11.4-101.fc18.x86_64
> > >>I thought it was a 3.14ish one, building one to try there...
> > >The kernel must be 3.14-rcX, the tool can be any version.
> > I don't have time to do a git bisect, but I can narrow the window to
> > 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
> > perf-top --stdio runs fine on the former and shows the problem on
> > the latter.
>
> Humm,
>
> /*
> * Either timeout expired or we got an EINTR due to
> * SIGWINCH, refresh screen in both cases.
> */
> switch (poll(&stdin_poll, 1, delay_msecs)) {
> And poll is returning 1:
> 951.068 ( 0.002 ms): poll(ufds: 0x7ff660befbb0, nfds: 1, timeout_msecs: 2000) = 1
We go to the getc(stdin) and it returns EOF :-\
- Arnaldo
On Thu, Feb 6, 2014 at 8:28 PM, Arnaldo Carvalho de Melo
<[email protected]> wrote:
> Em Thu, Feb 06, 2014 at 05:21:31PM -0200, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
>> > On 2/6/14, 8:24 AM, Stephane Eranian wrote:
>> > >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
>> > >>>>I am using tip.git. Or try 3.11, 3.10.
>
>> > >>But my tests are on top of:
>
>> > >>[acme@ssdandy linux]$ uname -r
>> > >>3.11.4-101.fc18.x86_64
>
>> > >>I thought it was a 3.14ish one, building one to try there...
>
>> > >The kernel must be 3.14-rcX, the tool can be any version.
>
>> > I don't have time to do a git bisect, but I can narrow the window to
>> > 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
>> > perf-top --stdio runs fine on the former and shows the problem on
>> > the latter.
>>
>> Humm,
>>
>> /*
>> * Either timeout expired or we got an EINTR due to
>> * SIGWINCH, refresh screen in both cases.
>> */
>> switch (poll(&stdin_poll, 1, delay_msecs)) {
>
>> And poll is returning 1:
>
>> 951.068 ( 0.002 ms): poll(ufds: 0x7ff660befbb0, nfds: 1, timeout_msecs: 2000) = 1
>
> We go to the getc(stdin) and it returns EOF :-\
>
Doesn't poll() return 0 if timeout, and 1 if descriptor in this case?
So you're saying you get 1 and getc() returns nothing to read.
Does stdin get closed somehow?
Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
> On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> ><[email protected]> wrote:
> >>Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
> >>>Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
> >>>>On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
> >>>><[email protected]> wrote:
> >>>>>Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
> >>>>>>If you run perf top on 3.14 but you force --stdio mode, perf top
> >>>>>>goes crazy and constantly refreshes the output.
> >>>>>>It does that with many older versions of the perf as well on 3.14.
> >>>>>>It runs fine with newt mode.
> >>>>>>Works fine with my 3.11 kernel. So something must be broken
> >>>>>>with 3.14.
> >>>>>>Can you reproduce the problem as well?
> >>>>>Not so far, using my perf/urgent branch:
> >>>>I am using tip.git. Or try 3.11, 3.10.
> >>But my tests are on top of:
> >>[acme@ssdandy linux]$ uname -r
> >>3.11.4-101.fc18.x86_64
> >>I thought it was a 3.14ish one, building one to try there...
> >>
> >The kernel must be 3.14-rcX, the tool can be any version.
>
> I don't have time to do a git bisect, but I can narrow the window to
> 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
> perf-top --stdio runs fine on the former and shows the problem on
> the latter.
Bisected it down to:
eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
commit eb3e4668bd9e0bbda592e830e889f137e44ec9e4
Author: Peter Hurley <[email protected]>
Date: Mon Dec 2 14:24:42 2013 -0500
n_tty: Un-inline slow-path n_tty_receive_char()
Commit e60d27c4d8b33ba20896b76b6558f061bc6460ff,
n_tty: Factor LNEXT processing from per-char i/o path,
mistakenly inlined the non-inline alias, n_tty_receive_char(),
for the inline function, n_tty_receive_char_inline().
As n_tty_receive_char() is intended for slow-path char
processing only, un-inline it.
Signed-off-by: Peter Hurley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
:040000 040000 80215819e331ff95d80aa7c8a6a05f8c74d1fdb6 41a856dfeb6769e47c7689c92d91db497dfcc8cf M drivers
[acme@fedora20 linux]$
In a hurry now, will continue later, trying to understand what is the problem
introduced by the above cset...
Need to revert just this one to confirm that it is the culprit, etc.
- Arnaldo
Hi Arnaldo,
On 02/10/2014 04:03 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
>> On 2/6/14, 8:24 AM, Stephane Eranian wrote:
>>> On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
>>> <[email protected]> wrote:
>>>> Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
>>>>> Em Thu, Feb 06, 2014 at 02:58:01PM +0100, Stephane Eranian escreveu:
>>>>>> On Thu, Feb 6, 2014 at 2:56 PM, Arnaldo Carvalho de Melo
>>>>>> <[email protected]> wrote:
>>>>>>> Em Wed, Feb 05, 2014 at 10:25:09PM +0100, Stephane Eranian escreveu:
>>>>>>>> If you run perf top on 3.14 but you force --stdio mode, perf top
>>>>>>>> goes crazy and constantly refreshes the output.
>
>>>>>>>> It does that with many older versions of the perf as well on 3.14.
>>>>>>>> It runs fine with newt mode.
>
>>>>>>>> Works fine with my 3.11 kernel. So something must be broken
>>>>>>>> with 3.14.
>
>>>>>>>> Can you reproduce the problem as well?
>
>>>>>>> Not so far, using my perf/urgent branch:
>
>>>>>> I am using tip.git. Or try 3.11, 3.10.
>
>>>> But my tests are on top of:
>
>>>> [acme@ssdandy linux]$ uname -r
>>>> 3.11.4-101.fc18.x86_64
>
>>>> I thought it was a 3.14ish one, building one to try there...
>>>>
>>> The kernel must be 3.14-rcX, the tool can be any version.
>>
>> I don't have time to do a git bisect, but I can narrow the window to
>> 3.13-rc6 and 3.14-rc1. Just happened to update a server yesterday.
>> perf-top --stdio runs fine on the former and shows the problem on
>> the latter.
>
> Bisected it down to:
>
> eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
> commit eb3e4668bd9e0bbda592e830e889f137e44ec9e4
> Author: Peter Hurley <[email protected]>
> Date: Mon Dec 2 14:24:42 2013 -0500
>
> n_tty: Un-inline slow-path n_tty_receive_char()
>
> Commit e60d27c4d8b33ba20896b76b6558f061bc6460ff,
> n_tty: Factor LNEXT processing from per-char i/o path,
> mistakenly inlined the non-inline alias, n_tty_receive_char(),
> for the inline function, n_tty_receive_char_inline().
>
> As n_tty_receive_char() is intended for slow-path char
> processing only, un-inline it.
>
> Signed-off-by: Peter Hurley <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> :040000 040000 80215819e331ff95d80aa7c8a6a05f8c74d1fdb6 41a856dfeb6769e47c7689c92d91db497dfcc8cf M drivers
> [acme@fedora20 linux]$
>
> In a hurry now, will continue later, trying to understand what is the problem
> introduced by the above cset...
>
> Need to revert just this one to confirm that it is the culprit, etc.
Thanks for the report and bisect. Seems unlikely this commit is the
cause, but very likely to be some change I made since 3.13, since
I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
this on 3.12 + the patch stack from me for 3.13 and 3.14.
I'm looking into this now.
Regards,
Peter Hurley
Em Mon, Feb 10, 2014 at 09:15:42PM -0500, Peter Hurley escreveu:
> >Bisected it down to:
> >eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
> >Author: Peter Hurley <[email protected]>
> >Date: Mon Dec 2 14:24:42 2013 -0500
> > n_tty: Un-inline slow-path n_tty_receive_char()
> >In a hurry now, will continue later, trying to understand what is the problem
> >introduced by the above cset...
> >Need to revert just this one to confirm that it is the culprit, etc.
> Thanks for the report and bisect. Seems unlikely this commit is the
> cause, but very likely to be some change I made since 3.13, since
> I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
> this on 3.12 + the patch stack from me for 3.13 and 3.14.
> I'm looking into this now.
I just reverted just this cset and the problem persisted, so I'll wait
for you on this one :-)
- Arnaldo
On 02/11/2014 07:14 AM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 10, 2014 at 09:15:42PM -0500, Peter Hurley escreveu:
>>> Bisected it down to:
>
>>> eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
>>> Author: Peter Hurley <[email protected]>
>>> Date: Mon Dec 2 14:24:42 2013 -0500
>
>>> n_tty: Un-inline slow-path n_tty_receive_char()
>
>>> In a hurry now, will continue later, trying to understand what is the problem
>>> introduced by the above cset...
>
>>> Need to revert just this one to confirm that it is the culprit, etc.
>
>> Thanks for the report and bisect. Seems unlikely this commit is the
>> cause, but very likely to be some change I made since 3.13, since
>> I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
>> this on 3.12 + the patch stack from me for 3.13 and 3.14.
>
>> I'm looking into this now.
>
> I just reverted just this cset and the problem persisted, so I'll wait
> for you on this one :-)
I did the same with the same result. So I'm re-bisecting on one machine
and tracing on another.
Regards,
Peter Hurley
On 02/11/2014 07:14 AM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 10, 2014 at 09:15:42PM -0500, Peter Hurley escreveu:
>>> Bisected it down to:
>
>>> eb3e4668bd9e0bbda592e830e889f137e44ec9e4 is the first bad commit
>>> Author: Peter Hurley <[email protected]>
>>> Date: Mon Dec 2 14:24:42 2013 -0500
>
>>> n_tty: Un-inline slow-path n_tty_receive_char()
>
>>> In a hurry now, will continue later, trying to understand what is the problem
>>> introduced by the above cset...
>
>>> Need to revert just this one to confirm that it is the culprit, etc.
>
>> Thanks for the report and bisect. Seems unlikely this commit is the
>> cause, but very likely to be some change I made since 3.13, since
>> I can repro on 3.14-rc1 but not on 3.13.2 -stable. I can also repro
>> this on 3.12 + the patch stack from me for 3.13 and 3.14.
>
>> I'm looking into this now.
>
> I just reverted just this cset and the problem persisted, so I'll wait
> for you on this one :-)
My bisection pointed to:
eafbe67f84761d787802e5113d895a316b6292fe is the first bad commit
commit eafbe67f84761d787802e5113d895a316b6292fe
Author: Peter Hurley <[email protected]>
Date: Mon Dec 2 14:24:45 2013 -0500
n_tty: Refactor input_available_p() by call site
Apologies for the breakage; the patch below should fix it.
Regards,
Peter Hurley
--- >% ---
From: Peter Hurley <[email protected]>
Date: Tue, 11 Feb 2014 10:10:07 -0500
Subject: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0
Commit eafbe67f84761d787802e5113d895a316b6292fe,
n_tty: Refactor input_available_p() by call site
broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
When TIME_CHAR and MIN_CHAR are both 0, input is available if the
read_cnt is 1 (not 0).
Reported-by: Stephane Eranian <[email protected]>
Signed-off-by: Peter Hurley <[email protected]>
---
drivers/tty/n_tty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index cb8017a..2747a3b 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1896,7 +1896,7 @@ err:
static inline int input_available_p(struct tty_struct *tty, int poll)
{
struct n_tty_data *ldata = tty->disc_data;
- int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
+ int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
if (ldata->icanon && !L_EXTPROC(tty)) {
if (ldata->canon_head != ldata->read_tail)
--
1.8.1.2
On 2/11/14, 9:49 AM, Peter Hurley wrote:
> From: Peter Hurley <[email protected]>
> Date: Tue, 11 Feb 2014 10:10:07 -0500
> Subject: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0
>
> Commit eafbe67f84761d787802e5113d895a316b6292fe,
> n_tty: Refactor input_available_p() by call site
> broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
>
> When TIME_CHAR and MIN_CHAR are both 0, input is available if the
> read_cnt is 1 (not 0).
>
> Reported-by: Stephane Eranian <[email protected]>
> Signed-off-by: Peter Hurley <[email protected]>
> ---
> drivers/tty/n_tty.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index cb8017a..2747a3b 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -1896,7 +1896,7 @@ err:
> static inline int input_available_p(struct tty_struct *tty, int poll)
> {
> struct n_tty_data *ldata = tty->disc_data;
> - int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
> + int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
>
> if (ldata->icanon && !L_EXTPROC(tty)) {
> if (ldata->canon_head != ldata->read_tail)
>
Worked for me.
Tested-by: David Ahern <[email protected]>
On Tue, 2014-02-11 at 11:49 -0500, Peter Hurley wrote:
> From: Peter Hurley <[email protected]>
> Date: Tue, 11 Feb 2014 10:10:07 -0500
> Subject: [PATCH] n_tty: Fix poll() when TIME_CHAR and MIN_CHAR == 0
>
> Commit eafbe67f84761d787802e5113d895a316b6292fe,
> n_tty: Refactor input_available_p() by call site
> broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
>
> When TIME_CHAR and MIN_CHAR are both 0, input is available if the
> read_cnt is 1 (not 0).
>
> Reported-by: Stephane Eranian <[email protected]>
> Signed-off-by: Peter Hurley <[email protected]>
> ---
> drivers/tty/n_tty.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index cb8017a..2747a3b 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -1896,7 +1896,7 @@ err:
> static inline int input_available_p(struct tty_struct *tty, int poll)
> {
> struct n_tty_data *ldata = tty->disc_data;
> - int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
> + int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
>
> if (ldata->icanon && !L_EXTPROC(tty)) {
> if (ldata->canon_head != ldata->read_tail)
Reported-by: Eric Dumazet <[email protected]>
Tested-by: Eric Dumazet <[email protected]>
Thanks guys
> Commit eafbe67f84761d787802e5113d895a316b6292fe,
> n_tty: Refactor input_available_p() by call site
> broke poll() when TIME_CHAR(tty) and MIN_CHAR(tty) are both 0.
>
> When TIME_CHAR and MIN_CHAR are both 0, input is available if the
> read_cnt is 1 (not 0).
>
> Reported-by: Stephane Eranian <[email protected]>
> Signed-off-by: Peter Hurley <[email protected]>
Thanks,
Tested-by: Arnaldo Carvalho de Melo <[email protected]>
- Arnaldo
> ---
> drivers/tty/n_tty.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> index cb8017a..2747a3b 100644
> --- a/drivers/tty/n_tty.c
> +++ b/drivers/tty/n_tty.c
> @@ -1896,7 +1896,7 @@ err:
> static inline int input_available_p(struct tty_struct *tty, int poll)
> {
> struct n_tty_data *ldata = tty->disc_data;
> - int amt = poll && !TIME_CHAR(tty) ? MIN_CHAR(tty) : 1;
> + int amt = poll && !TIME_CHAR(tty) && MIN_CHAR(tty) ? MIN_CHAR(tty) : 1;
>
> if (ldata->icanon && !L_EXTPROC(tty)) {
> if (ldata->canon_head != ldata->read_tail)
> --
> 1.8.1.2