From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Christian Zigotzky <chzigotzky@xenosoft•de>
Cc: linuxppc-dev@lists•ozlabs.org
Subject: Re: PASEMI: PA6T board doesn't boot with the RC1 of kernel 4.2 anymore
Date: Thu, 09 Jul 2015 08:36:30 +1000 [thread overview]
Message-ID: <1436394990.3948.113.camel@kernel.crashing.org> (raw)
In-Reply-To: <559D653F.2060307@xenosoft.de>
On Wed, 2015-07-08 at 20:00 +0200, Christian Zigotzky wrote:
> Dear Linuxppc-dev mailing list,
>
> I used git bisect and found out that the following commit is the problem.
>
> commit 3ceaccdf92073d193f0bfbe24280dd736e3fed86
> Author: Dave Hansen <dave.hansen@linux•intel.com>
There is no way that commit affects anything on that platform, it only
changes a file in arch/x86 that isn't compiled on a powerpc build. You
must have made a mistake in your bisection, possibly the one "sometimes
boots" should be considered good, but I can't say for sure.
Michael has a PA6T board at work, so I assume he will see if he can
reproduce.
Ben.
>
> Log:
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-git
>
> git bisect start b953c0d234bc72e8489d3bf51a276c5c4ec85345 (Linux 4.1)
>
> git bisect bad d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 (Linux 4.2-rc1)
>
> Output:
>
> Bisecting: 6261 revisions left to test after this (roughly 13 steps)
> [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.2-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
>
> ----
>
> git bisect bad
>
> Output:
>
> Bisecting: 3295 revisions left to test after this (roughly 12 steps)
> [4e241557fc1cb560bd9e77ca1b4a9352732a5427] Merge tag 'for-linus' of
> git://git.kernel.org/pub/scm/virt/kvm/kvm
>
> ----
>
> git bisect bad
>
> Output:
>
> Bisecting: 1625 revisions left to test after this (roughly 11 steps)
> [44d21c3f3a2ef2f58b18bda64c52c99e723f3f4a] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
>
> ----
>
> git bisect bad
>
> Output:
>
> Bisecting: 712 revisions left to test after this (roughly 10 steps)
> [e75c73ad64478c12b3a44b86a3e7f62a4f65b93e] Merge branch
> 'x86-fpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>
> ----
>
> git bisect bad (sometimes the kernel boots but the mouse doesn't work)
>
> Output:
>
> Bisecting: 371 revisions left to test after this (roughly 9 steps)
> [c58267e9fa7b0345dd9006939254701e3622ca6a] Merge branch
> 'perf-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>
> ----
>
> git bisect good
>
> Output:
>
> Bisecting: 185 revisions left to test after this (roughly 8 steps)
> [59a36d16be8f9f68410f1bd396577fb7f31ae877] x86/fpu: Factor out
> fpu/regset.h from fpu/internal.h
>
> ----
>
> git bisect good
>
> Output:
>
> Bisecting: 93 revisions left to test after this (roughly 7 steps)
> [23b7776290b10297fe2cae0fb5f166a4f2c68121] Merge branch
> 'sched-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>
> ----
>
> git bisect good
>
> Output:
>
> Bisecting: 46 revisions left to test after this (roughly 6 steps)
> [0c4109bec0a6cde471bef3a21cd6f8384a614469] x86/fpu/xstate: Fix up bad
> get_xsave_addr() assumptions
>
> ----
>
> git bisect good
>
> Output:
>
> Bisecting: 19 revisions left to test after this (roughly 5 steps)
> [cfe3eceb7a2eb91284d5605c5315249bb165e9d3] Merge branch
> 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>
> ----
>
> git bisect good
>
> Output:
>
> Bisecting: 9 revisions left to test after this (roughly 3 steps)
> [cd4996dce18b619bd7b3acf75c91f49c77f05a97] x86/mpx: Trace allocation of
> new bounds tables
>
> ----
>
> git bisect good
>
> Output:
>
> Bisecting: 4 revisions left to test after this (roughly 2 steps)
> [613fcb7d3c79ec25b5913a6aa974c9047c31e68c] x86/mpx: Support 32-bit
> binaries on 64-bit kernels
>
> ----
>
> git bisect good
>
> Output:
>
> Bisecting: 2 revisions left to test after this (roughly 1 step)
> [bea03c50b871a2fa922f31ad7c9993bb4fc7b192] x86/mpx: Do not count MPX
> VMAs as neighbors when unmapping
>
> ----
>
> git bisect bad (sometimes the kernel boots but the mouse doesn't work)
>
> Output:
>
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [3ceaccdf92073d193f0bfbe24280dd736e3fed86] x86/mpx: Rewrite the unmap code
>
> ----
>
> git bisect bad (sometimes the kernel boots but the mouse doesn't work)
>
> Output:
>
> 3ceaccdf92073d193f0bfbe24280dd736e3fed86 is the first bad commit
> commit 3ceaccdf92073d193f0bfbe24280dd736e3fed86
> Author: Dave Hansen <dave.hansen@linux•intel.com>
> Date: Sun Jun 7 11:37:06 2015 -0700
>
> x86/mpx: Rewrite the unmap code
>
> The MPX code needs to clear out bounds tables for memory which
> is no longer in use. We do this when a userspace mapping is
> torn down (unmapped).
>
> There are two modes:
>
> 1. An entire bounds table becomes unused, and can be freed
> and its pointer removed from the bounds directory. This
> happens either when a large mapping is torn down, or when
> a small mapping is torn down and it is the last mapping
> "covered" by a bounds table.
>
> 2. Only part of a bounds table becomes unused, in which case
> we free the backing memory as if MADV_DONTNEED was called.
>
> The old code was a spaghetti mess of "edge" bounds tables
> where the edges were handled specially, even if we were
> unmapping an entire one. Non-edge bounds tables are always
> fully unmapped, but share a different code path from the edge
> ones. The old code had a bug where it was unmapping too much
> memory. I worked on fixing it for two days and gave up.
>
> I didn't write the original code. I didn't particularly like
> it, but it worked, so I left it. After my debug session, I
> realized it was undebuggagle *and* buggy, so out it went.
>
> I also wrote a new unmapping test program which uncovers bugs
> pretty nicely.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux•intel.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix•de>
> Cc: Andrew Morton <akpm@linux-foundation•org>
> Cc: Dave Hansen <dave@sr71•net>
> Cc: H. Peter Anvin <hpa@zytor•com>
> Cc: Linus Torvalds <torvalds@linux-foundation•org>
> Cc: Peter Zijlstra <peterz@infradead•org>
> Link:
> http://lkml.kernel.org/r/20150607183706.DCAEC67D@viggo.jf.intel.com
> Signed-off-by: Ingo Molnar <mingo@kernel•org>
>
> :040000 040000 d6809ce6030ff42a5813da4a94971888d8ad67c9
> a0514265bbf313aba996e5606c00881acc62b220 M arch
>
> ----
>
> Cheers,
>
> Christian
>
>
> On 07 July 2015 2:44 PM, Christian Zigotzky wrote:
> >
> >
> > Error messages images:
> >
> > http://forum.hyperion-entertainment.biz/download/file.php?id=1772&mode=view
> >
> > http://forum.hyperion-entertainment.biz/download/file.php?id=1774&mode=view
> >
> >
> > -- Christian
> >
> > On 07 July 2015 12:50 PM Christian Zigotzky wrote:
> >> Dear Linuxppc-dev mailing list,
> >>
> >> I compiled a kernel from the git on Tuesday 23rd of June 2015. It
> >> didn't boot with my PASEMI PA6T board.
> >>
> >> Error messages:
> >>
> >> Oops: Kernel access of bad area, sig: 11 [#1]
> >>
> >> .sb600_8259_cascade+0x4c/0xac (unreliable)
> >> .schedule+0x74/0x9c (unreliable)
> >>
> >> Kernel panic - not syncing: Fatal exception in interrupt
> >>
> >> I compiled the RC1 of kernel 4.2 last Sunday. Unfortunately it didn't
> >> boot either. The kernel 4.1 and 4.1.1 boot without any problems.
> >>
> >> Could someone please explain me why it doesn't boot anymore?
> >>
> >> I would like to thank you very much in advance for helping me.
> >>
> >> If you have any questions, please don't hesitate to ask. I'm looking
> >> forward to getting your reply.
> >>
> >>
> >> Kind regards,
> >>
> >> Christian Zigotzky
> >>
> >>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists•ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists•ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists•ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
next prev parent reply other threads:[~2015-07-08 22:36 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-14 4:27 [PATCH 00/10] Move MSI related PCI controller ops to pci_controller_ops Daniel Axtens
2015-04-14 4:27 ` [PATCH 01/10] powerpc: Add MSI operations to pci_controller_ops struct Daniel Axtens
2015-04-14 4:27 ` [PATCH 02/10] powerpc/powernv: Move MSI-related ops to pci_controller_ops Daniel Axtens
2015-04-14 4:27 ` [PATCH 03/10] powerpc/cell: " Daniel Axtens
2015-04-14 4:27 ` [PATCH 04/10] powerpc/pseries: " Daniel Axtens
2015-04-14 4:27 ` [PATCH 05/10] powerpc/fsl_msi: " Daniel Axtens
2015-04-14 4:27 ` [PATCH 06/10] powerpc/ppc4xx_msi: " Daniel Axtens
2015-04-14 4:28 ` [PATCH 07/10] powerpc/ppc4xx_hsta_msi: " Daniel Axtens
2015-04-14 4:28 ` [PATCH 08/10] powerpc/mpic_pasemi_msi: " Daniel Axtens
2015-07-07 10:50 ` PASEMI: PA6T board doesn't boot with the RC1 of kernel 4.2 anymore Christian Zigotzky
2015-07-07 11:25 ` Christian Zigotzky
2015-07-07 12:44 ` Christian Zigotzky
2015-07-08 18:00 ` Christian Zigotzky
2015-07-08 22:36 ` Benjamin Herrenschmidt [this message]
2015-07-09 1:42 ` Michael Ellerman
2015-07-09 5:19 ` Christian Zigotzky
2015-07-09 7:07 ` Michael Ellerman
2015-07-09 7:53 ` Benjamin Herrenschmidt
2015-07-09 8:50 ` Christian Zigotzky
2015-07-09 9:12 ` Christian Zigotzky
2015-07-09 9:52 ` Denis Kirjanov
2015-07-09 10:37 ` Christian Zigotzky
2015-07-13 6:47 ` Benjamin Herrenschmidt
2015-07-13 9:33 ` Denis Kirjanov
2015-07-09 22:27 ` Christian Zigotzky
2015-07-10 6:51 ` Christian Zigotzky
2015-07-13 6:44 ` Benjamin Herrenschmidt
2015-04-14 4:28 ` [PATCH 09/10] powerpc/mpic_u3msi: Move MSI-related ops to pci_controller_ops Daniel Axtens
2015-04-14 4:28 ` [PATCH 10/10] powerpc: Remove MSI-related PCI controller ops from ppc_md Daniel Axtens
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=1436394990.3948.113.camel@kernel.crashing.org \
--to=benh@kernel$(echo .)crashing.org \
--cc=chzigotzky@xenosoft$(echo .)de \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox