From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: v3.13-rc6+ regression (ARM board)
Date: Thu, 2 Jan 2014 11:14:55 +0100 [thread overview]
Message-ID: <20140102101455.GG10158@pengutronix.de> (raw)
In-Reply-To: <m3txdmu2ez.fsf@t19.piap.pl>
Hello Krzysztof,
On Thu, Jan 02, 2014 at 11:02:44AM +0100, Krzysztof Ha?asa wrote:
> >> There seems to be a regression in v3.13-rc6+ (up to current tip =
> >> 71ce176ee6ed1735b9a1160a5704a915d13849b1).
> >>
> >> Board is Gateworks Cambria, CPU Intel IXP435 ARM big endian, gcc 4.7.3.
> >> The board boots correctly and works (shell mostly, and SSHD) for about
> >> 50 seconds. After 52-54 seconds, it frozes dead without any console
> >> (UART) output.
> >>
> >> Bisecting shows 5e30025a319910695f5010dc0fb53a23299da14d as the first
> >> bad commit. Interestingly it's a merge:
>
> Reverting 1ca7d67cf5d5a2aef26a8d9afd789006fa098347 on top of current tip
> (9a0bb2966efbf30a71c128c3af63307d8b5f5fc0) fixes my issue.
>
> What now?
>
> 1ca7d67cf5d5a2aef26a8d9afd789006fa098347:
> seqcount: Add lockdep functionality to seqcount/seqlock structures
>
> Currently seqlocks and seqcounts don't support lockdep.
>
> After running across a seqcount related deadlock in the timekeeping
> code, I used a less-refined and more focused variant of this patch
> to narrow down the cause of the issue.
>
> This is a first-pass attempt to properly enable lockdep functionality
> on seqlocks and seqcounts.
>
> Since seqcounts are used in the vdso gettimeofday code, I've provided
> non-lockdep accessors for those needs.
>
> I've also handled one case where there were nested seqlock writers
> and there may be more edge cases.
>
> Comments and feedback would be appreciated!
So it seems to be that 1ca7d67cf5d5a2aef26a8d9afd789006fa098347 doesn't
like to be combined with some other commit from
5e30025a319910695f5010dc0fb53a23299da14d^2..5e30025a319910695f5010dc0fb53a23299da14d^.
What you can do is:
git bisect start 5e30025a319910695f5010dc0fb53a23299da14d^ b8a216269ec0ce2e961d32e6d640d7010b8a818e
The bad commit is the tip of Linus' tree when he created the bad merge
commit. The good one is the base of the merged tree. To check if a tree
is good or bad do:
git merge --no-commit 5e30025a319910695f5010dc0fb53a23299da14d^2
test test test
git reset --hard
git bisect good ... or ... git bisect bad
That should find the commit that makes your board break in combination
with 1ca7d67cf5d5a2aef26a8d9afd789006fa098347.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: "Krzysztof Hałasa" <khalasa@piap.pl>
Cc: Willy Tarreau <w@1wt.eu>, John Stultz <john.stultz@linaro.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org,
Ingo Molnar <mingo@kernel.org>
Subject: Re: v3.13-rc6+ regression (ARM board)
Date: Thu, 2 Jan 2014 11:14:55 +0100 [thread overview]
Message-ID: <20140102101455.GG10158@pengutronix.de> (raw)
In-Reply-To: <m3txdmu2ez.fsf@t19.piap.pl>
Hello Krzysztof,
On Thu, Jan 02, 2014 at 11:02:44AM +0100, Krzysztof Hałasa wrote:
> >> There seems to be a regression in v3.13-rc6+ (up to current tip =
> >> 71ce176ee6ed1735b9a1160a5704a915d13849b1).
> >>
> >> Board is Gateworks Cambria, CPU Intel IXP435 ARM big endian, gcc 4.7.3.
> >> The board boots correctly and works (shell mostly, and SSHD) for about
> >> 50 seconds. After 52-54 seconds, it frozes dead without any console
> >> (UART) output.
> >>
> >> Bisecting shows 5e30025a319910695f5010dc0fb53a23299da14d as the first
> >> bad commit. Interestingly it's a merge:
>
> Reverting 1ca7d67cf5d5a2aef26a8d9afd789006fa098347 on top of current tip
> (9a0bb2966efbf30a71c128c3af63307d8b5f5fc0) fixes my issue.
>
> What now?
>
> 1ca7d67cf5d5a2aef26a8d9afd789006fa098347:
> seqcount: Add lockdep functionality to seqcount/seqlock structures
>
> Currently seqlocks and seqcounts don't support lockdep.
>
> After running across a seqcount related deadlock in the timekeeping
> code, I used a less-refined and more focused variant of this patch
> to narrow down the cause of the issue.
>
> This is a first-pass attempt to properly enable lockdep functionality
> on seqlocks and seqcounts.
>
> Since seqcounts are used in the vdso gettimeofday code, I've provided
> non-lockdep accessors for those needs.
>
> I've also handled one case where there were nested seqlock writers
> and there may be more edge cases.
>
> Comments and feedback would be appreciated!
So it seems to be that 1ca7d67cf5d5a2aef26a8d9afd789006fa098347 doesn't
like to be combined with some other commit from
5e30025a319910695f5010dc0fb53a23299da14d^2..5e30025a319910695f5010dc0fb53a23299da14d^.
What you can do is:
git bisect start 5e30025a319910695f5010dc0fb53a23299da14d^ b8a216269ec0ce2e961d32e6d640d7010b8a818e
The bad commit is the tip of Linus' tree when he created the bad merge
commit. The good one is the base of the merged tree. To check if a tree
is good or bad do:
git merge --no-commit 5e30025a319910695f5010dc0fb53a23299da14d^2
test test test
git reset --hard
git bisect good ... or ... git bisect bad
That should find the commit that makes your board break in combination
with 1ca7d67cf5d5a2aef26a8d9afd789006fa098347.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2014-01-02 10:14 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-31 10:37 v3.13-rc6+ regression (ARM board) Krzysztof Hałasa
2013-12-31 10:37 ` Krzysztof Hałasa
2013-12-31 10:45 ` Willy Tarreau
2013-12-31 10:45 ` Willy Tarreau
2014-01-02 10:02 ` Krzysztof Hałasa
2014-01-02 10:02 ` Krzysztof Hałasa
2014-01-02 10:14 ` Uwe Kleine-König [this message]
2014-01-02 10:14 ` Uwe Kleine-König
2014-01-02 12:07 ` Krzysztof Hałasa
2014-01-02 12:07 ` Krzysztof Hałasa
2014-01-02 19:38 ` Linus Torvalds
2014-01-02 19:38 ` Linus Torvalds
2014-01-02 20:03 ` John Stultz
2014-01-02 20:03 ` John Stultz
2014-01-02 20:30 ` John Stultz
2014-01-02 20:30 ` John Stultz
2014-01-02 20:42 ` Stephen Boyd
2014-01-02 20:42 ` Stephen Boyd
2014-01-02 20:52 ` John Stultz
2014-01-02 20:52 ` John Stultz
2014-01-02 20:43 ` Linus Torvalds
2014-01-02 20:43 ` Linus Torvalds
2014-01-02 21:34 ` John Stultz
2014-01-02 21:34 ` John Stultz
2014-01-02 21:54 ` [PATCH] sched_clock: Disable seqlock lockdep usage in sched_clock John Stultz
2014-01-02 21:54 ` John Stultz
2014-01-02 22:15 ` Linus Torvalds
2014-01-02 22:15 ` Linus Torvalds
2014-01-02 22:21 ` John Stultz
2014-01-02 22:21 ` John Stultz
2014-01-02 23:11 ` [PATCH 1/2] seqlock: Use raw_ prefix instead of _no_lockdep John Stultz
2014-01-02 23:11 ` John Stultz
2014-01-02 23:11 ` [PATCH 2/2] sched_clock: Disable seqlock lockdep usage in sched_clock John Stultz
2014-01-02 23:11 ` John Stultz
2014-01-03 0:46 ` Stephen Boyd
2014-01-03 0:46 ` Stephen Boyd
2014-01-03 6:05 ` Krzysztof Hałasa
2014-01-03 6:05 ` Krzysztof Hałasa
2014-01-12 18:42 ` [tip:core/urgent] sched_clock: Disable seqlock lockdep usage in sched_clock() tip-bot for John Stultz
2014-01-14 19:18 ` John Stultz
2014-01-15 6:38 ` Ingo Molnar
2014-01-03 0:46 ` [PATCH 1/2] seqlock: Use raw_ prefix instead of _no_lockdep Stephen Boyd
2014-01-03 0:46 ` Stephen Boyd
2014-01-03 0:50 ` Linus Torvalds
2014-01-03 0:50 ` Linus Torvalds
2014-01-04 0:28 ` John Stultz
2014-01-04 0:28 ` John Stultz
2014-01-06 10:10 ` Peter Zijlstra
2014-01-06 10:10 ` Peter Zijlstra
2014-01-12 18:42 ` [tip:core/urgent] " tip-bot for John Stultz
2014-01-03 6:01 ` v3.13-rc6+ regression (ARM board) Krzysztof Hałasa
2014-01-03 6:01 ` Krzysztof Hałasa
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=20140102101455.GG10158@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.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.