All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: lkml <linux-kernel@vger.kernel.org>
Cc: linux-serial@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jiri Slaby <jslaby@suse.cz>,
	Peter Hurley <peter@hurleysoftware.com>
Subject: Re: n_tty_write() going into schedule but NOT coming out
Date: Mon, 1 Apr 2013 19:27:47 +0530	[thread overview]
Message-ID: <5159925B.5050806@synopsys.com> (raw)
In-Reply-To: <5156DC21.20901@synopsys.com>

Hi,

Any thoughts: I observe the same issue even with CONFIG_PREEMPT and
CONFIG_PREEMPT_COUNT

-Vineet

On 03/30/2013 06:05 PM, Vineet Gupta wrote:
> Hi,
> 
> I've been stress testing ARC Linux 3.8 (same happens for 3.9-rc3 as well). The
> setup has 3 telnet sessions, each running find . -name "*" in a loop.
> The platform is a FPGA @ 80 MHz, running a single core ARC700 so kernel .config
> has !SMP and PREEMPT_NONE.
> 
> After ~10 mins of run, I see that one of the telnet session gets stuck (and later
> the 2nd one as well), while system is still alive, 3rd telnet is running find merrily.
> 
> [ARCLinux]$ ps
> ....
>     7 root       0:00 inetd
>    62 root       0:00 -/bin/sh
>    64 root       1:34 telnetd -i -l /bin/sh
>    65 root       0:00 /bin/sh
>    75 root       1:47 telnetd -i -l /bin/sh
>    76 root       0:00 /bin/sh
>    79 root       0:53 telnetd -i -l /bin/sh
>    80 root       0:00 /bin/sh
>   281 root       0:00 find / -name *	<--- stuck
>   358 root       0:03 find / -name *	<--- stuck
>   377 root       0:00 find / -name *
>   378 root       0:00 ps
> 
> Hung find task is sitting in the schedule() call in n_tty_write()
> 
> [ARCLinux]$ cat /proc/281/stack
> [<8065945e>] n_tty_write+0x23a/0x424
> [<80655cd4>] tty_write+0x1ac/0x2d4
> [<805976ba>] vfs_write+0x92/0x110
> [<80597816>] sys_write+0x4e/0x88
> [<8050e780>] ret_from_system_call+0x0/0x4
> 
> This task never resumes out of schedule() - verified by putting a hardware
> breakpoint on next insn - using a JTAG host debugger.
> 
> Attached are .config, /proc/281/sched, /proc/schedstat, /proc/sched_debug
> 
> My knowledge of schedular is close to none, hence any tips to debug this further
> would be much appreciated.
> 
> 
> TIA,
> -Vineet
> 

WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: lkml <linux-kernel@vger.kernel.org>
Cc: <linux-serial@vger.kernel.org>, Ingo Molnar <mingo@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	Jiri Slaby <jslaby@suse.cz>,
	Peter Hurley <peter@hurleysoftware.com>
Subject: Re: n_tty_write() going into schedule but NOT coming out
Date: Mon, 1 Apr 2013 19:27:47 +0530	[thread overview]
Message-ID: <5159925B.5050806@synopsys.com> (raw)
In-Reply-To: <5156DC21.20901@synopsys.com>

Hi,

Any thoughts: I observe the same issue even with CONFIG_PREEMPT and
CONFIG_PREEMPT_COUNT

-Vineet

On 03/30/2013 06:05 PM, Vineet Gupta wrote:
> Hi,
> 
> I've been stress testing ARC Linux 3.8 (same happens for 3.9-rc3 as well). The
> setup has 3 telnet sessions, each running find . -name "*" in a loop.
> The platform is a FPGA @ 80 MHz, running a single core ARC700 so kernel .config
> has !SMP and PREEMPT_NONE.
> 
> After ~10 mins of run, I see that one of the telnet session gets stuck (and later
> the 2nd one as well), while system is still alive, 3rd telnet is running find merrily.
> 
> [ARCLinux]$ ps
> ....
>     7 root       0:00 inetd
>    62 root       0:00 -/bin/sh
>    64 root       1:34 telnetd -i -l /bin/sh
>    65 root       0:00 /bin/sh
>    75 root       1:47 telnetd -i -l /bin/sh
>    76 root       0:00 /bin/sh
>    79 root       0:53 telnetd -i -l /bin/sh
>    80 root       0:00 /bin/sh
>   281 root       0:00 find / -name *	<--- stuck
>   358 root       0:03 find / -name *	<--- stuck
>   377 root       0:00 find / -name *
>   378 root       0:00 ps
> 
> Hung find task is sitting in the schedule() call in n_tty_write()
> 
> [ARCLinux]$ cat /proc/281/stack
> [<8065945e>] n_tty_write+0x23a/0x424
> [<80655cd4>] tty_write+0x1ac/0x2d4
> [<805976ba>] vfs_write+0x92/0x110
> [<80597816>] sys_write+0x4e/0x88
> [<8050e780>] ret_from_system_call+0x0/0x4
> 
> This task never resumes out of schedule() - verified by putting a hardware
> breakpoint on next insn - using a JTAG host debugger.
> 
> Attached are .config, /proc/281/sched, /proc/schedstat, /proc/sched_debug
> 
> My knowledge of schedular is close to none, hence any tips to debug this further
> would be much appreciated.
> 
> 
> TIA,
> -Vineet
> 


  reply	other threads:[~2013-04-01 13:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-30 12:35 n_tty_write() going into schedule but NOT coming out Vineet Gupta
2013-03-30 12:35 ` Vineet Gupta
2013-04-01 13:57 ` Vineet Gupta [this message]
2013-04-01 13:57   ` Vineet Gupta
2013-04-01 15:10   ` Peter Hurley
2013-04-02 11:09     ` Vineet Gupta
2013-04-02 11:09       ` Vineet Gupta
2013-04-02 13:26     ` Vineet Gupta
2013-04-02 13:26       ` Vineet Gupta
2013-04-02 13:38       ` Peter Hurley
2013-04-05 19:52       ` Peter Hurley
2013-04-06  9:32         ` Vineet Gupta
2013-04-06  9:32           ` Vineet Gupta
2013-04-03  5:44 ` Ilya Zykov
2013-04-03  7:42   ` Vineet Gupta
2013-04-03  7:42     ` Vineet Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5159925B.5050806@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peter@hurleysoftware.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.