--- On Wed, 6/6/12, Steffen Rumler wrote:
> From: Steffen Rumler
> Subject: [PATCH] kernel panic during kernel module load (powerpc specific
> part)
> To: "ext Benjamin Herrenschmidt" , pau...@samba.org
> Cc: "Wrobel Heinz-R39252" , "Michael Eller
Hi,
The patch below is intended to fix the following problem.
According to the PowerPC EABI specification, the GPR r11 is assigned
the dedicated function to point to the previous stack frame.
In the powerpc-specific kernel module loader, do_plt_call()
(in arch/powerpc/kernel/module_32.c), the GP
On Wed, 2012-06-06 at 09:36 +0200, Steffen Rumler wrote:
>
> how should we continue here ?
> There is the kernel panic, I've described.
>
> Technically, there is an conflict between the code generated by the
> compiler and the loader in module_32.c, at least by using -Os.
> Because the prologue/e
On Fri, Jun 01, 2012 at 11:33:37AM +, Wrobel Heinz-R39252 wrote:
I believe that the basic premise is that you should provide a directly
reachable copy of the save/rstore functions, even if this means that
you need several copies of the functions.
I just fixed a very similar problem with g
On Tue, 2012-06-05 at 12:44 +0200, Gabriel Paubert wrote:
> On Tue, Jun 05, 2012 at 08:00:42AM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-06-04 at 13:03 +0200, Gabriel Paubert wrote:
> > > There is no conflict to the ABI. These functions are supposed to be
> > > directly reachable from w
On Tue, 2012-06-05 at 13:32 +0200, Gabriel Paubert wrote:
> - gcc-4.6 and gcc-4.7 behave identically, if -Os is set, they
> generate by default lmw/stmw. But if I combine -Os with
> -mno-multiple, they call the helper functions.
>
> In other words, on this system, gcc-4.4 is broken but should
On Tue, Jun 05, 2012 at 08:00:42AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-06-04 at 13:03 +0200, Gabriel Paubert wrote:
> > There is no conflict to the ABI. These functions are supposed to be
> > directly reachable from whatever code
> > section may need them.
> >
> > Now I have a ques
On Tue, Jun 05, 2012 at 08:00:42AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-06-04 at 13:03 +0200, Gabriel Paubert wrote:
> > There is no conflict to the ABI. These functions are supposed to be
> > directly reachable from whatever code
> > section may need them.
> >
> > Now I have a ques
On Mon, 2012-06-04 at 13:03 +0200, Gabriel Paubert wrote:
> There is no conflict to the ABI. These functions are supposed to be
> directly reachable from whatever code
> section may need them.
>
> Now I have a question: how did you get the need for this?
>
> None of my kernels uses them:
> - if I
On Mon, Jun 04, 2012 at 09:43:01AM +0200, Steffen Rumler wrote:
> Let me summarize the situation:
>
>+ According to Freescale, EABI assigns a dedicated function to register
> r11.
>+ The ELF sections .text and .init.text may trigger the usage of the
> trampoline code.
>+ The trampoli
On Fri, Jun 01, 2012 at 11:33:37AM +, Wrobel Heinz-R39252 wrote:
> > > I believe that the basic premise is that you should provide a directly
> > > reachable copy of the save/rstore functions, even if this means that
> > you need several copies of the functions.
> >
> > I just fixed a very sim
I believe that the basic premise is that you should provide a directly
reachable copy of the save/rstore functions, even if this means that
you need several copies of the functions.
I just fixed a very similar problem with grub2 in fact. It was using r0
and trashing the saved LR that way.
The
> > I believe that the basic premise is that you should provide a directly
> > reachable copy of the save/rstore functions, even if this means that
> you need several copies of the functions.
>
> I just fixed a very similar problem with grub2 in fact. It was using r0
> and trashing the saved LR th
On Thu, 2012-05-31 at 13:04 +0200, Gabriel Paubert wrote:
> I believe that the basic premise is that you should provide a directly
> reachable copy
> of the save/rstore functions, even if this means that you need several copies
> of the functions.
I just fixed a very similar problem with grub2
On Thu, May 31, 2012 at 07:04:42AM +, Wrobel Heinz-R39252 wrote:
> Michael,
>
> > On Wed, 2012-05-30 at 16:33 +0200, Steffen Rumler wrote:
> > > I've found the following root cause:
> > >
> > > (6) Unfortunately, the trampoline code (do_plt_call()) is using
> > register r11 to setup the j
Michael,
> On Wed, 2012-05-30 at 16:33 +0200, Steffen Rumler wrote:
> > I've found the following root cause:
> >
> > (6) Unfortunately, the trampoline code (do_plt_call()) is using
> register r11 to setup the jump.
> >It looks like the prologue and epilogue are using also the
> re
On Wed, 2012-05-30 at 16:33 +0200, Steffen Rumler wrote:
> Hi,
>
> The system crashes inside the return of the init entry point of the kernel
> module.
>
> I've found the following root cause:
>
> (6) Unfortunately, the trampoline code (do_plt_call()) is using register
> r11 to setup the
Hi,
We have seen the following kernel panic, happened during loading a kernel
module:
[ 536.107430] Unable to handle kernel paging request for data at address
0xd76a907c
[ 536.114922] Faulting instruction address: 0xc770
[ 536.119891] Oops: Kernel access of bad area, sig: 11
18 matches
Mail list logo
