From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: lkp@lists.01.org
Subject: Re: [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600
Date: Wed, 24 Feb 2016 21:50:22 +0900 [thread overview]
Message-ID: <20160224125022.GA516@swordfish> (raw)
In-Reply-To: <20160224114614.GY3305@pathway.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]
Hello,
On (02/24/16 12:46), Petr Mladek wrote:
[..]
> > and you get the NMI watchdog softlockup because you have a whole bunch of
> >
> > "of_overlay_destroy: Could not find overlay #6"
> > "### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6"
> >
> > messages to print. seems that somehitng just pushes them in a loop.
> > there are too many of them:
>
> This sounds like a reasonable explanation. It seems that
> of_unittest_destroy_tracked_overlays() really ended in an infinite
> loop.
>
> But I am still curious why the softlookup points to
>
> [ 33.497718] EIP is at vprintk_emit+0x1ea/0x600
>
> Also there is on the stack
>
> [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
> [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
>
> I would expect that the soft lookup happens in console_unlock()
> called with IRQs disabled. It seems to me that of_unittest_overlay()
> is called with IRQs enabled.
watchdog has two different parts: hrtimer part (via IRQ) checks the
touch_ts and wakeups the updater smpboot kthread; and updater kthread,
that updates touch_ts. to get a lockup you can just keep the preemption
disabled for 20+ seconds, so updater kthread will not update touch_ts.
the next hrtimer irq will detect lockup. and the .config we have is
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
that can add up to the issue.
(well, at least watchdog was working this way the last time I saw it).
> I want to be sure that the patch in printk() did not introduce
> a deadlock that is visible only under a high printk load.
sure. I did additional intensive tests today, and saw no issues.
schematically, something like this:
u64 start = local_lock() >> 31UL:
{ preempt_disable(), local_irq_save() }
while (1) {
u64 now = local_clock() >> 31UL;
if (now - start > TIMEOUT)
goto out;
pr_err(">>>>>\n");
}
out:
{ preempt_enable(), local_irq_restore() }
> I guess that the softlookup was not visible before the
> printk patch was applied. I wonder if the patch made something
> worse. It was supposed to improve things but...
I think the softlockup under the given conditions (endless printk and
no preemption) will show up regardless the patches being applied; but
I see you point, of course.
-ss
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Petr Mladek <pmladek-IBi9RG/b67k@public.gmane.org>
Cc: Sergey Senozhatsky
<sergey.senozhatsky.work-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
kernel test robot
<ying.huang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
lkp-JC7UmRfGjtg@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Frank Rowand
<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Calvin Owens <calvinowens-b10kYP2dOMg@public.gmane.org>,
Dave Jones
<davej-rdkfGonbjUTCLXcRTR1eJlpr/1R2p/CL@public.gmane.org>,
Kyle McMartin <kyle-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Jan Kara <jack-IBi9RG/b67k@public.gmane.org>,
Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>,
Sergey Senozhatsky
<sergey.senozhatsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [lkp] [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600
Date: Wed, 24 Feb 2016 21:50:22 +0900 [thread overview]
Message-ID: <20160224125022.GA516@swordfish> (raw)
In-Reply-To: <20160224114614.GY3305-KsEp0d+Q8qECVLCxKZUutA@public.gmane.org>
Hello,
On (02/24/16 12:46), Petr Mladek wrote:
[..]
> > and you get the NMI watchdog softlockup because you have a whole bunch of
> >
> > "of_overlay_destroy: Could not find overlay #6"
> > "### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6"
> >
> > messages to print. seems that somehitng just pushes them in a loop.
> > there are too many of them:
>
> This sounds like a reasonable explanation. It seems that
> of_unittest_destroy_tracked_overlays() really ended in an infinite
> loop.
>
> But I am still curious why the softlookup points to
>
> [ 33.497718] EIP is at vprintk_emit+0x1ea/0x600
>
> Also there is on the stack
>
> [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
> [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
>
> I would expect that the soft lookup happens in console_unlock()
> called with IRQs disabled. It seems to me that of_unittest_overlay()
> is called with IRQs enabled.
watchdog has two different parts: hrtimer part (via IRQ) checks the
touch_ts and wakeups the updater smpboot kthread; and updater kthread,
that updates touch_ts. to get a lockup you can just keep the preemption
disabled for 20+ seconds, so updater kthread will not update touch_ts.
the next hrtimer irq will detect lockup. and the .config we have is
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
that can add up to the issue.
(well, at least watchdog was working this way the last time I saw it).
> I want to be sure that the patch in printk() did not introduce
> a deadlock that is visible only under a high printk load.
sure. I did additional intensive tests today, and saw no issues.
schematically, something like this:
u64 start = local_lock() >> 31UL:
{ preempt_disable(), local_irq_save() }
while (1) {
u64 now = local_clock() >> 31UL;
if (now - start > TIMEOUT)
goto out;
pr_err(">>>>>\n");
}
out:
{ preempt_enable(), local_irq_restore() }
> I guess that the softlookup was not visible before the
> printk patch was applied. I wonder if the patch made something
> worse. It was supposed to improve things but...
I think the softlockup under the given conditions (endless printk and
no preemption) will show up regardless the patches being applied; but
I see you point, of course.
-ss
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
kernel test robot <ying.huang@linux.intel.com>,
lkp@01.org, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Calvin Owens <calvinowens@fb.com>,
Dave Jones <davej@codemonkey.org.uk>,
Kyle McMartin <kyle@kernel.org>, Tejun Heo <tj@kernel.org>,
Jan Kara <jack@suse.com>, Stephen Rothwell <sfr@canb.auug.org.au>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [lkp] [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600
Date: Wed, 24 Feb 2016 21:50:22 +0900 [thread overview]
Message-ID: <20160224125022.GA516@swordfish> (raw)
In-Reply-To: <20160224114614.GY3305@pathway.suse.cz>
Hello,
On (02/24/16 12:46), Petr Mladek wrote:
[..]
> > and you get the NMI watchdog softlockup because you have a whole bunch of
> >
> > "of_overlay_destroy: Could not find overlay #6"
> > "### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6"
> >
> > messages to print. seems that somehitng just pushes them in a loop.
> > there are too many of them:
>
> This sounds like a reasonable explanation. It seems that
> of_unittest_destroy_tracked_overlays() really ended in an infinite
> loop.
>
> But I am still curious why the softlookup points to
>
> [ 33.497718] EIP is at vprintk_emit+0x1ea/0x600
>
> Also there is on the stack
>
> [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
> [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
>
> I would expect that the soft lookup happens in console_unlock()
> called with IRQs disabled. It seems to me that of_unittest_overlay()
> is called with IRQs enabled.
watchdog has two different parts: hrtimer part (via IRQ) checks the
touch_ts and wakeups the updater smpboot kthread; and updater kthread,
that updates touch_ts. to get a lockup you can just keep the preemption
disabled for 20+ seconds, so updater kthread will not update touch_ts.
the next hrtimer irq will detect lockup. and the .config we have is
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
that can add up to the issue.
(well, at least watchdog was working this way the last time I saw it).
> I want to be sure that the patch in printk() did not introduce
> a deadlock that is visible only under a high printk load.
sure. I did additional intensive tests today, and saw no issues.
schematically, something like this:
u64 start = local_lock() >> 31UL:
{ preempt_disable(), local_irq_save() }
while (1) {
u64 now = local_clock() >> 31UL;
if (now - start > TIMEOUT)
goto out;
pr_err(">>>>>\n");
}
out:
{ preempt_enable(), local_irq_restore() }
> I guess that the softlookup was not visible before the
> printk patch was applied. I wonder if the patch made something
> worse. It was supposed to improve things but...
I think the softlockup under the given conditions (endless printk and
no preemption) will show up regardless the patches being applied; but
I see you point, of course.
-ss
next prev parent reply other threads:[~2016-02-24 12:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160223131538.GA2048@swordfish>
2016-02-23 15:53 ` [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600 Sergey Senozhatsky
2016-02-23 15:53 ` [lkp] " Sergey Senozhatsky
2016-02-24 1:19 ` Sergey Senozhatsky
2016-02-24 1:19 ` [lkp] " Sergey Senozhatsky
2016-02-24 1:19 ` Sergey Senozhatsky
2016-02-24 11:46 ` Petr Mladek
2016-02-24 11:46 ` [lkp] " Petr Mladek
2016-02-24 11:46 ` Petr Mladek
2016-02-24 12:50 ` Sergey Senozhatsky [this message]
2016-02-24 12:50 ` Sergey Senozhatsky
2016-02-24 12:50 ` Sergey Senozhatsky
2016-02-24 15:12 ` Sergey Senozhatsky
2016-02-24 15:12 ` [lkp] " Sergey Senozhatsky
2016-02-25 5:10 ` Sergey Senozhatsky
2016-02-25 5:10 ` [lkp] " Sergey Senozhatsky
2016-02-25 5:10 ` Sergey Senozhatsky
2016-03-02 10:30 ` Petr Mladek
2016-03-02 10:30 ` [lkp] " Petr Mladek
2016-03-02 10:41 ` Sergey Senozhatsky
2016-03-02 10:41 ` [lkp] " Sergey Senozhatsky
2016-02-23 0:55 kernel test robot
2016-02-23 0:55 ` [lkp] " kernel test robot
2016-02-23 16:55 ` Petr Mladek
2016-02-23 16:55 ` [lkp] " Petr Mladek
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=20160224125022.GA516@swordfish \
--to=sergey.senozhatsky@gmail.com \
--cc=lkp@lists.01.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.