On 02/05/2019 10:10 AM, Michael Ellerman wrote:
Christophe Leroy writes:
Le 20/12/2018 à 23:35, Benjamin Herrenschmidt a écrit :
/*
* MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
@@ -205,20 +208,46 @@ transfer_to_handler_cont:
mflrr9
lwz
On Tue, 2019-02-05 at 10:45 +0100, Christophe Leroy wrote:
> > > I tested it on the 8xx with the below changes in addition. No issue seen
> > > so far.
> >
> > Thanks !
> >
> > I'll merge that in.
>
> I'm currently working on a refactorisation and simplification of
> exception and syscall entry
Le 20/12/2018 à 06:40, Benjamin Herrenschmidt a écrit :
Hi folks !
Why trying to figure out why we had occasionally lockdep barf about
interrupt state on ppc32 (440 in my case but I could reproduce on e500
as well using qemu), I realized that we are still doing something
rather gothic and wro
Christophe Leroy writes:
> Le 20/12/2018 à 23:35, Benjamin Herrenschmidt a écrit :
>>
/*
* MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
@@ -205,20 +208,46 @@ transfer_to_handler_cont:
mflrr9
lwz r11,0(r9)
Le 20/12/2018 à 23:35, Benjamin Herrenschmidt a écrit :
/*
* MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
@@ -205,20 +208,46 @@ transfer_to_handler_cont:
mflrr9
lwz r11,0(r9) /* virtual address of handler */
lwz r9,4(
Le 20/12/2018 à 06:40, Benjamin Herrenschmidt a écrit :
Hi folks !
Why trying to figure out why we had occasionally lockdep barf about
interrupt state on ppc32 (440 in my case but I could reproduce on e500
as well using qemu), I realized that we are still doing something
rather gothic and wro
Le 20/12/2018 à 06:40, Benjamin Herrenschmidt a écrit :
Hi folks !
Why trying to figure out why we had occasionally lockdep barf about
interrupt state on ppc32 (440 in my case but I could reproduce on e500
as well using qemu), I realized that we are still doing something
rather gothic and wro
> > /*
> >* MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
> > @@ -205,20 +208,46 @@ transfer_to_handler_cont:
> > mflrr9
> > lwz r11,0(r9) /* virtual address of handler */
> > lwz r9,4(r9)/* where to go when done */
> >
On 12/20/2018 05:40 AM, Benjamin Herrenschmidt wrote:
Hi folks !
Why trying to figure out why we had occasionally lockdep barf about
interrupt state on ppc32 (440 in my case but I could reproduce on e500
as well using qemu), I realized that we are still doing something
rather gothic and wrong
Hi folks !
Why trying to figure out why we had occasionally lockdep barf about
interrupt state on ppc32 (440 in my case but I could reproduce on e500
as well using qemu), I realized that we are still doing something
rather gothic and wrong on 32-bit which we stopped doing on 64-bit
a while ago.
W
10 matches
Mail list logo