headers
Christian Kujau | 1 Jun 2011 01:50
Picon

3.0-rc1: powerpc hangs at Kernel virtual memory layout

Hi,

trying to boot 3.0-rc1 on powerpc32 only progresses until:

  > Kernel virtual memory layout:
  >   * 0xfffcf000..0xfffff000  : fixmap

And then the system hangs, does not respond to keyboard (sysrq does not 
seem to work on this PowerBook G4). But after a while the system reboots 
itself, so I guess the machine panicked but did not print anything on the 
screen.

Full messages (picture), config & (working) dmesg:

   http://nerdbynature.de/bits/3.0-rc1/

I'm currently trying to bisect this, so far I have:

----------------------
git bisect start
# good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf
# bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1
git bisect bad 55922c9d1b84b89cb946c777fddccb3247e7df2c
# bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next' 
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
git bisect bad c44dead70a841d90ddc01968012f323c33217c9e
# bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if 
lowerdev in a bond
git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Jun 2011 02:25

Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout

On Tue, 2011-05-31 at 16:50 -0700, Christian Kujau wrote:
> Hi,
> 
> trying to boot 3.0-rc1 on powerpc32 only progresses until:
> 
>   > Kernel virtual memory layout:
>   >   * 0xfffcf000..0xfffff000  : fixmap
> 
> And then the system hangs, does not respond to keyboard (sysrq does not 
> seem to work on this PowerBook G4). But after a while the system reboots 
> itself, so I guess the machine panicked but did not print anything on the 
> screen.
> 
> Full messages (picture), config & (working) dmesg:
> 
>    http://nerdbynature.de/bits/3.0-rc1/
> 
> I'm currently trying to bisect this, so far I have:

Hrm, I had it working on a pair of powerbooks yesterday. Can you try
something like "udbg-immortal" on your kernel command line to see if
that makes a difference in the output ?

Cheers,
Ben.

> ----------------------
> git bisect start
> # good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf
(Continue reading)

Permalink | Reply | 8 comments |
headers
Christian Kujau | 1 Jun 2011 02:48
Picon

Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout

On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
> Hrm, I had it working on a pair of powerbooks yesterday. Can you try
> something like "udbg-immortal" on your kernel command line to see if
> that makes a difference in the output ?

I'll try in a minute.

In the meantime, "git bisect" behaves kinda weird, I don't know what went 
wrong here:

 $ git bisect start
 $ git bisect good         # Linux 2.6.39
 $ git bisect bad v3.0-rc1 # Linux 3.0-rc1
 $ git bisect bad          # c44dead70a...
 $ git bisect bad          # d93515611b..

...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2. 
Maybe "git bisect" got confused with that whole 2.6.x -> 3.0 renaming?

Christian.

[0] http://nerdbynature.de/bits/3.0-rc1/
--

-- 
BOFH excuse #383:

Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet.
Permalink | Reply | 0 comments |
headers
Christian Kujau | 1 Jun 2011 03:08
Picon

Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout

On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
> On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote:
> > Hrm, I had it working on a pair of powerbooks yesterday. Can you try
> > something like "udbg-immortal" on your kernel command line to see if
> > that makes a difference in the output ?
> 
> I'll try in a minute.

Wow, it really did make a difference:

  http://nerdbynature.de/bits/3.0-rc1/
  * linux-3.0_powerpc_2.jpg
  * linux-3.0_powerpc_2.mp4 (only a few(!) seconds long,
    best to view with the slider in VLC oder Quicktime, to
    get at least a grasp what lead to linux-3.0_powerpc_2.jpg)

Thanks,
Christian.
--

-- 
BOFH excuse #45:

virus attack, luser responsible
Permalink | Reply | 0 comments |
headers
Christian Kujau | 1 Jun 2011 03:22
Picon

[PATCH] document udbg-immortal

Back in 2006 the "udbg-immortal" kernel option has been introduced:

  > commit 3b5e905ee3bd23e9311951890aba57a0dbc81ca4
  > Author: Benjamin Herrenschmidt <benh <at> au1.ibm.com>
  > Date:   Wed Jun 7 12:06:20 2006 +1000
  >
  >  [PATCH] powerpc: Add udbg-immortal kernel option

...but I could not find it documented anywhere in the sources. 
This patch adds it to Documentation/kernel-parameters.txt.

Signed-off-by: Christian Kujau <lists <at> nerdbynature.de>

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index cc85a92..5d0df23 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
 <at>  <at>  -2520,6 +2520,11  <at>  <at>  bytes respectively. Such letter suffixes can also be entirely omitted.
 			<port#>,<js1>,<js2>,<js3>,<js4>,<js5>,<js6>,<js7>
 			See also Documentation/input/joystick-parport.txt

+	udbg-immortal	[PPC] When debugging early kernel crashes that
+			happen after console_init() and before a proper 
+			console driver takes over, this boot options might
+			help "seeing" what's going on.
+
 	uhash_entries=	[KNL,NET]
 			Set number of hash buckets for UDP/UDP-Lite connections

Thanks,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Kujau | 1 Jun 2011 05:02
Picon

Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout

(Cc'in Linus)

On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
> In the meantime, "git bisect" behaves kinda weird, I don't know what went 
> wrong here:
> 
>  $ git bisect start
>  $ git bisect good         # Linux 2.6.39
>  $ git bisect bad v3.0-rc1 # Linux 3.0-rc1
>  $ git bisect bad          # c44dead70a...
>  $ git bisect bad          # d93515611b..
> 
> ...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2. 
> Maybe "git bisect" got confused with that whole 2.6.x -> 3.0 renaming?

Hm, I tried again, from a clean v3.0-rc1 (git reset --hard), but after the 
2nd "git bad" I'm at 2.6.39-rc2 again - while I /should/ be somwhere 
inbetween v2.6.39..v3.0-rc1, right?

Help, please!
Christian.

[0] http://nerdbynature.de/bits/3.0-rc1/
--

-- 
BOFH excuse #54:

Evil dogs hypnotised the night shift
Permalink | Reply | 0 comments |
headers
Will Drewry | 1 Jun 2011 05:10

[PATCH v3 11/13] powerpc: select HAVE_SECCOMP_FILTER and provide seccomp_execve

Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
system call numbering for execve and selecting HAVE_SECCOMP_FILTER.

Signed-off-by: Will Drewry <wad <at> chromium.org>
---
 arch/powerpc/Kconfig               |    1 +
 arch/powerpc/include/asm/seccomp.h |    2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8f4d50b..0bd4574 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
 <at>  <at>  -137,6 +137,7  <at>  <at>  config PPC
 	select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
 	select HAVE_GENERIC_HARDIRQS
 	select HAVE_SPARSE_IRQ
+	select HAVE_SECCOMP_FILTER
 	select IRQ_PER_CPU
 	select GENERIC_IRQ_SHOW
 	select GENERIC_IRQ_SHOW_LEVEL
diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h
index 00c1d91..3cb9cc1 100644
--- a/arch/powerpc/include/asm/seccomp.h
+++ b/arch/powerpc/include/asm/seccomp.h
 <at>  <at>  -7,10 +7,12  <at>  <at> 
 #define __NR_seccomp_write __NR_write
 #define __NR_seccomp_exit __NR_exit
 #define __NR_seccomp_sigreturn __NR_rt_sigreturn
+#define __NR_seccomp_execve __NR_execve
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Jun 2011 05:49

Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout

On Tue, 2011-05-31 at 20:02 -0700, Christian Kujau wrote:
> (Cc'in Linus)
> 
> On Tue, 31 May 2011 at 17:48, Christian Kujau wrote:
> > In the meantime, "git bisect" behaves kinda weird, I don't know what went 
> > wrong here:
> > 
> >  $ git bisect start
> >  $ git bisect good         # Linux 2.6.39
> >  $ git bisect bad v3.0-rc1 # Linux 3.0-rc1
> >  $ git bisect bad          # c44dead70a...
> >  $ git bisect bad          # d93515611b..
> > 
> > ...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2. 
> > Maybe "git bisect" got confused with that whole 2.6.x -> 3.0 renaming?
> 
> Hm, I tried again, from a clean v3.0-rc1 (git reset --hard), but after the 
> 2nd "git bad" I'm at 2.6.39-rc2 again - while I /should/ be somwhere 
> inbetween v2.6.39..v3.0-rc1, right?

Kernel version is totally irrelevant when bisecting. You are not walking
through a linear series of patches but a complex tree of merges which
might have forked off different versions in the first place.

Cheers,
Ben.
Permalink | Reply | 0 comments |
headers
Paul Mackerras | 1 Jun 2011 07:20
Picon
Favicon

Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7

On Tue, May 31, 2011 at 02:50:20PM +0200, Alexander Graf wrote:
> 
> On 31.05.2011, at 14:35, Paul Mackerras wrote:
> 
> > On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote:
> > 
> >> Thinking about the testability of this a bit more ... how much
> >> effort would it be to get this code running on a 970MP with SLOF?
> >> There should only be a few POWER7 specific pieces, right?
> > 
> > Do you have a 970MP that has a usable hypervisor mode, i.e. not an
> > Apple machine?  The 970s in Apple machines have the HV hard-wired to
> > 1, which means they do have a hypervisor mode but it isn't any use.
> > 
> > If you do have such a machine, then we would have to look at some
> > details like the instruction sequence for the partition switch, and
> > make sure we don't try to use SMT4 mode.  Also, I believe we will have
> > to flush the TLB on partition switches, since Power processors prior
> > to POWER7 didn't tag the TLB entries with the partition ID.
> > 
> > So it should be quite feasible if you have a non-Apple machine.
> > I will check whether the 970MP machines that Terrasoft were
> > distributing would be suitable.  We have one of them in the lab.
> 
> That's the one I was thinking of and yes, I have one available. That
> way I could test 99% of your code, you don't have to release
> hardware, and everyone's happy :).

I checked our YDL PowerStation and it does appear to have a usable
hypervisor mode. :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Mackerras | 1 Jun 2011 07:11
Picon
Favicon

Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode

On Wed, Jun 01, 2011 at 12:34:43AM +0200, Segher Boessenkool wrote:

> There's a loop of 128 iterations of 3 insns.
> 
> I'm not saying it is actually bad, just that that 50 is slightly off ;-)

That would be the TLB invalidation.  On POWER7 we only need to do that
if the virtual cpu last ran on a different physical cpu, or if this
physical cpu last ran a different virtual cpu in the same partition.
So hopefully we don't have to do it very often.

The reason we have to do it in that case is to allow the optimization
where we use tlbiel for TLB invalidations if the guest claims that
the translation being invalidated was only ever used on this virtual
cpu.  That means that we have to guard against stale TLB entries left
behind when a virtual cpu moves from one physical cpu to another.

Paul.
Permalink | Reply | 0 comments |

Gmane