* 2.6.39-rc1: f23eb2b breaks console output @ 2011-04-04 19:15 Alexander Beregalov 2011-04-04 19:42 ` [REGRESSION] " Sitsofe Wheeler 0 siblings, 1 reply; 6+ messages in thread From: Alexander Beregalov @ 2011-04-04 19:15 UTC (permalink / raw) To: Linux Kernel Mailing List, Linus Torvalds, Greg KH, Alan Cox [-- Attachment #1: Type: text/plain, Size: 501 bytes --] 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 [-- Attachment #2: config.gz --] [-- Type: application/x-gzip, Size: 11078 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] 2.6.39-rc1: f23eb2b breaks console output 2011-04-04 19:15 2.6.39-rc1: f23eb2b breaks console output Alexander Beregalov @ 2011-04-04 19:42 ` Sitsofe Wheeler 2011-04-04 19:59 ` Linus Torvalds 0 siblings, 1 reply; 6+ messages in thread From: Sitsofe Wheeler @ 2011-04-04 19:42 UTC (permalink / raw) To: Alexander Beregalov Cc: Linux Kernel Mailing List, Linus Torvalds, Greg KH, Alan Cox 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] 2.6.39-rc1: f23eb2b breaks console output 2011-04-04 19:42 ` [REGRESSION] " Sitsofe Wheeler @ 2011-04-04 19:59 ` Linus Torvalds 2011-04-04 20:42 ` Alexander Beregalov 0 siblings, 1 reply; 6+ messages in thread From: Linus Torvalds @ 2011-04-04 19:59 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Alexander Beregalov, Linux Kernel Mailing List, Greg KH, Alan Cox [-- Attachment #1: Type: text/plain, Size: 1278 bytes --] On Mon, Apr 4, 2011 at 12:42 PM, Sitsofe Wheeler <sitsofe@yahoo.com> 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 [-- Attachment #2: patch.diff --] [-- Type: text/x-patch, Size: 1520 bytes --] drivers/tty/n_tty.c | 6 ++++++ drivers/tty/tty_buffer.c | 4 +--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index 428f4fe..0ad3288 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -95,6 +95,7 @@ static void n_tty_set_room(struct tty_struct *tty) { /* tty->read_cnt is not read locked ? */ int left = N_TTY_BUF_SIZE - tty->read_cnt - 1; + int old_left; /* * If we are doing input canonicalization, and there are no @@ -104,7 +105,12 @@ static void n_tty_set_room(struct tty_struct *tty) */ if (left <= 0) left = tty->icanon && !tty->canon_data; + old_left = tty->receive_room; tty->receive_room = left; + + /* Did this open up the receive buffer? We may need to flip */ + if (left && !old_left) + schedule_work(&tty->buf.work); } static void put_tty_queue_nolock(unsigned char c, struct tty_struct *tty) diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c index b945121..f1a7918 100644 --- a/drivers/tty/tty_buffer.c +++ b/drivers/tty/tty_buffer.c @@ -442,10 +442,8 @@ static void flush_to_ldisc(struct work_struct *work) line discipline as we want to empty the queue */ if (test_bit(TTY_FLUSHPENDING, &tty->flags)) break; - if (!tty->receive_room || seen_tail) { - schedule_work(&tty->buf.work); + if (!tty->receive_room || seen_tail) break; - } if (count > tty->receive_room) count = tty->receive_room; char_buf = head->char_buf_ptr + head->read; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] 2.6.39-rc1: f23eb2b breaks console output 2011-04-04 19:59 ` Linus Torvalds @ 2011-04-04 20:42 ` Alexander Beregalov 2011-04-04 21:06 ` Sitsofe Wheeler 0 siblings, 1 reply; 6+ messages in thread From: Alexander Beregalov @ 2011-04-04 20:42 UTC (permalink / raw) To: Linus Torvalds Cc: Sitsofe Wheeler, Linux Kernel Mailing List, Greg KH, Alan Cox On 4 April 2011 23:59, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Apr 4, 2011 at 12:42 PM, Sitsofe Wheeler <sitsofe@yahoo.com> 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] 2.6.39-rc1: f23eb2b breaks console output 2011-04-04 20:42 ` Alexander Beregalov @ 2011-04-04 21:06 ` Sitsofe Wheeler 2011-04-04 21:39 ` Linus Torvalds 0 siblings, 1 reply; 6+ messages in thread From: Sitsofe Wheeler @ 2011-04-04 21:06 UTC (permalink / raw) To: Alexander Beregalov Cc: Linus Torvalds, Linux Kernel Mailing List, Greg KH, Alan Cox On Tue, Apr 05, 2011 at 12:42:54AM +0400, Alexander Beregalov wrote: > On 4 April 2011 23:59, Linus Torvalds <torvalds@linux-foundation.org> 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 <sitsofe@yahoo.com> -- Sitsofe | http://sucs.org/~sits/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] 2.6.39-rc1: f23eb2b breaks console output 2011-04-04 21:06 ` Sitsofe Wheeler @ 2011-04-04 21:39 ` Linus Torvalds 0 siblings, 0 replies; 6+ messages in thread From: Linus Torvalds @ 2011-04-04 21:39 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Alexander Beregalov, Linux Kernel Mailing List, Greg KH, Alan Cox On Mon, Apr 4, 2011 at 2:06 PM, Sitsofe Wheeler <sitsofe@yahoo.com> wrote: > On Tue, Apr 05, 2011 at 12:42:54AM +0400, Alexander Beregalov wrote: >> On 4 April 2011 23:59, Linus Torvalds <torvalds@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-04-04 21:46 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-04-04 19:15 2.6.39-rc1: f23eb2b breaks console output Alexander Beregalov 2011-04-04 19:42 ` [REGRESSION] " Sitsofe Wheeler 2011-04-04 19:59 ` Linus Torvalds 2011-04-04 20:42 ` Alexander Beregalov 2011-04-04 21:06 ` Sitsofe Wheeler 2011-04-04 21:39 ` Linus Torvalds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®