Hi
commit f23eb2b2b28547fc70df82dd5049eb39bec5ba12 tty: stop using
"delayed_work" in the tty layer
breaks console output for me.
When I try to run a command with many output lines (like 'dmesg' or
'ps ax') console (both local or network) hangs up for 30-100 minutes.
It hangs not completely, it responses every 10-20 minutes with few
lines more on the screen.
LA becomes 10-20.
Reverting the commit returns things back to normal.
Anything else I can add to report?
It is UP x86, config is attached
On Mon, Apr 4, 2011 at 12:42 PM, Sitsofe Wheeler <[email protected]> wrote:
> On Mon, Apr 04, 2011 at 11:15:10PM +0400, Alexander Beregalov wrote:
>>
>> commit f23eb2b2b28547fc70df82dd5049eb39bec5ba12 tty: stop using
>> "delayed_work" in the tty layer
>> breaks console output for me.
>
> Same here - doing a dmesg in an xterm makes the machine hang for about
> 10 seconds and latencytop whinges that a raw SCSI command took 4000ms to
> complete (uniprocessor x86 EeePC 900).
>
> Additionally, you won't see this problem if you have CONFIG_PREEMPT set
> but as my config has CONFIG_PREEMPT_VOLUNTARY=y I do see this problem.
> Reverting f23eb2b2b28547fc70df82dd5049eb39bec5ba12 fixed the problem for
> me too.
Does this patch make a difference?
The tty ldisc flushing code had this crazy "reflush if we're full"
logic, which was apparently hiding a problem in N_TTY handling where
it wouldn't wake things up when the receive-room was opened up again.
When I made it not do timers, the "reflush" logic basically made for
an infinite loop (before, it used to instead basically poll for the
event on each timer tick instead).
The attached patch removes the reflush logic, and makes N_TTY instead
wake up the work when opening up the receive buffer again.
Linus
On Mon, Apr 04, 2011 at 11:15:10PM +0400, Alexander Beregalov wrote:
>
> commit f23eb2b2b28547fc70df82dd5049eb39bec5ba12 tty: stop using
> "delayed_work" in the tty layer
> breaks console output for me.
Same here - doing a dmesg in an xterm makes the machine hang for about
10 seconds and latencytop whinges that a raw SCSI command took 4000ms to
complete (uniprocessor x86 EeePC 900).
Additionally, you won't see this problem if you have CONFIG_PREEMPT set
but as my config has CONFIG_PREEMPT_VOLUNTARY=y I do see this problem.
Reverting f23eb2b2b28547fc70df82dd5049eb39bec5ba12 fixed the problem for
me too.
--
Sitsofe | http://sucs.org/~sits/
On 4 April 2011 23:59, Linus Torvalds <[email protected]> wrote:
> On Mon, Apr 4, 2011 at 12:42 PM, Sitsofe Wheeler <[email protected]> wrote:
>> On Mon, Apr 04, 2011 at 11:15:10PM +0400, Alexander Beregalov wrote:
>>>
>>> commit f23eb2b2b28547fc70df82dd5049eb39bec5ba12 tty: stop using
>>> "delayed_work" in the tty layer
>>> breaks console output for me.
>>
>> Same here - doing a dmesg in an xterm makes the machine hang for about
>> 10 seconds and latencytop whinges that a raw SCSI command took 4000ms to
>> complete (uniprocessor x86 EeePC 900).
>>
>> Additionally, you won't see this problem if you have CONFIG_PREEMPT set
>> but as my config has CONFIG_PREEMPT_VOLUNTARY=y I do see this problem.
>> Reverting f23eb2b2b28547fc70df82dd5049eb39bec5ba12 fixed the problem for
>> me too.
>
> Does this patch make a difference?
Yes, it works on top of 2.6.39-rc1-00184-g78fca1b9
Thanks
>
> The tty ldisc flushing code had this crazy "reflush if we're full"
> logic, which was apparently hiding a problem in N_TTY handling where
> it wouldn't wake things up when the receive-room was opened up again.
>
> When I made it not do timers, the "reflush" logic basically made for
> an infinite loop (before, it used to instead basically poll for the
> event on each timer tick instead).
>
> The attached patch removes the reflush logic, and makes N_TTY instead
> wake up the work when opening up the receive buffer again.
>
> Linus
>
On Tue, Apr 05, 2011 at 12:42:54AM +0400, Alexander Beregalov wrote:
> On 4 April 2011 23:59, Linus Torvalds <[email protected]> wrote:
> >
> > Does this patch make a difference?
> Yes, it works on top of 2.6.39-rc1-00184-g78fca1b9
This fixes the problem for me too (on top of
148086bb64694cc91624bab2a550d50f800eb4b7 ).
Tested-by: Sitsofe Wheeler <[email protected]>
--
Sitsofe | http://sucs.org/~sits/
On Mon, Apr 4, 2011 at 2:06 PM, Sitsofe Wheeler <[email protected]> wrote:
> On Tue, Apr 05, 2011 at 12:42:54AM +0400, Alexander Beregalov wrote:
>> On 4 April 2011 23:59, Linus Torvalds <[email protected]> wrote:
>> >
>> > Does this patch make a difference?
>> Yes, it works on top of 2.6.39-rc1-00184-g78fca1b9
>
> This fixes the problem for me too (on top of
> 148086bb64694cc91624bab2a550d50f800eb4b7 ).
I had that patch pending because Dave Jones had reported a less
extreme case of this earlier, but I never got a definitive ack from
him on it.
But with you two confirming it, it's now committed as commit
a5660b41af6a ("tty: fix endless work loop when the buffer fills up")
in my tree.
Thanks,
Linus