it either (for
the bootstatus flags).
Basically I need to check the CPU reset reason and I thought I would ask
first, before starting to write any code of my own.
Thanks,
Radu Rendec
Hi,
On Fri, 2018-08-24 at 16:20 +, Christophe Leroy wrote:
> > On 08/03/2018 04:36 PM, Radu Rendec wrote:
> >
> > Is there any kernel code that handles the "reset status register" (RSR)
> > on MPC83xx? I looked at arch/powerpc/platforms/83xx/misc.c, but
Hi,
On Mon, 2018-09-10 at 07:37 +0200, Christophe Leroy wrote:
> Le 10/09/2018 à 01:13, Radu Rendec a écrit :
> >
> > I'm using U-boot as well, but it's just not configured to read or clear
> > the RSR. I'm curious: if U-boot reads/clears the RSR in your case, how
> &
to that
file up to the latest master in Linus' tree, so I believe the problem is
still there in the latest kernel.
Should commit df1024ad8728 be reapplied?
Thanks,
Radu Rendec
actually tested it on
v4.9.115. On the other hand, the patch is trivial and I did check that
the NULL pointer dereference scenario is still valid on v4.20-rc4.
Best regards,
Radu Rendec
Radu Rendec (1):
Fix NULL pointer access in PowerPC MSI teardown code
arch/powerpc/kernel/msi.c | 9 -
1
do happen (MSI descriptors are
allocated before pci_msi_setup_msi_irqs() is called and need to be
cleaned up if that fails).
Signed-off-by: Radu Rendec
---
arch/powerpc/kernel/msi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/msi.c b/arch/powe
Hi Michael,
On Wed, Nov 28, 2018 at 6:00 AM Michael Ellerman wrote:
>
> Radu Rendec writes:
> >
> > The assumption in arch_teardown_msi_irqs() is wrong and results in a
> > function call on a NULL pointer. An example of how this can happen is
> > included in the a
Hi Christophe,
On Thu, 2018-09-13 at 10:21 +0200, Christophe LEROY wrote:
>
> Le 11/09/2018 à 00:17, Radu Rendec a écrit :
> >
> > The MPC83xx also has a watchdog and the kernel driver (mpc8xxx_wdt.c)
> > could also be improved to support the WDIOC_GETBOOTSTATUS ioctl
s layout.
I will continue to investigate, but I'm not familiar with the PowerPC
registers so it will take a while before I make sense of all the data
structures and macros. Hopefully this rings a bell to someone who is
already familiar with those and could figure out quickly what the
problem is.
Best r
On Thu, 2019-06-06 at 07:15 +0200, Christophe Leroy wrote:
>
> Le 05/06/2019 à 23:45, Radu Rendec a écrit :
> > Hi Everyone,
> >
> > I'm seeing some weird memory corruption that I have been able to isolate
> > to arch_ptrace() [arch/powerpc/kernel/ptra
On Mon, 2019-06-17 at 11:19 +1000, Daniel Axtens wrote:
> Radu Rendec <
> radu.ren...@gmail.com
> > writes:
>
> > Hi Everyone,
> >
> > I'm following up on the ptrace() problem that I reported a few days ago.
> > I believe my version of the code handles
= 0;
ptrace (PTRACE_POKEUSER, pid,
/* Coerce to a uintptr_t first to avoid potential gcc warning
8<--
Radu Rendec (1):
PPC32: fix ptrace() access to FPU registers
arch/powerpc/kernel/ptrace.c | 85 ++--
1 file changed, 52 insertions(+), 33 deletions(-)
--
2.20.1
() with
PTRACE_PEEKUSR/PTRACE_POKEUSR) seems to always read/write all FPU
registers whenever a traced task stops.
Signed-off-by: Radu Rendec
---
arch/powerpc/kernel/ptrace.c | 85 ++--
1 file changed, 52 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c
On Wed, 2019-06-19 at 10:36 +1000, Daniel Axtens wrote:
> Andreas Schwab <
> sch...@linux-m68k.org
> > writes:
>
> > On Jun 18 2019, Radu Rendec <
> > radu.ren...@gmail.com
> > > wrote:
> >
> > > Since you already have a workin
On Tue, 2019-06-18 at 16:42 +1000, Daniel Axtens wrote:
> Radu Rendec <
> radu.ren...@gmail.com
> > writes:
>
> > On Mon, 2019-06-17 at 11:19 +1000, Daniel Axtens wrote:
> > > Radu Rendec <
> > > radu.ren...@gmail.com
> > >
> > > &
On 02/20/2020 at 12:48 PM Christophe Leroy wrote:
> Le 20/02/2020 à 18:34, Radu Rendec a écrit :
> > On 02/20/2020 at 11:25 AM Christophe Leroy wrote:
> >> Le 20/02/2020 à 17:02, Radu Rendec a écrit :
> >>> On 02/20/2020 at 3:38 AM Christophe Leroy wrote:
>
On 02/18/2020 at 1:08 PM Christophe Leroy wrote:
> Le 18/02/2020 à 18:07, Radu Rendec a écrit :
> > The saved NIP seems to be broken inside machine_check_exception() on
> > MPC8378, running Linux 4.9.191. The value is 0x900 most of the times,
> > but I have seen other weird
On 02/20/2020 at 3:38 AM Christophe Leroy wrote:
> On 02/19/2020 10:39 PM, Radu Rendec wrote:
> > On 02/19/2020 at 4:21 PM Christophe Leroy wrote:
> >>> Interesting.
> >>>
> >>> 0x900 is the adress of the timer interrupt.
> >>>
> >&g
On 02/20/2020 at 11:25 AM Christophe Leroy wrote:
> Le 20/02/2020 à 17:02, Radu Rendec a écrit :
> > On 02/20/2020 at 3:38 AM Christophe Leroy wrote:
> >> On 02/19/2020 10:39 PM, Radu Rendec wrote:
> >>> On 02/19/2020 at 4:21 PM Christophe Leroy wrote:
> >>
On 02/19/2020 at 10:11 AM Radu Rendec wrote:
> On 02/18/2020 at 1:08 PM Christophe Leroy wrote:
> > Le 18/02/2020 à 18:07, Radu Rendec a écrit :
> > > The saved NIP seems to be broken inside machine_check_exception() on
> > > MPC8378, running Linux 4.9.191. The value
On 02/19/2020 at 4:21 PM Christophe Leroy wrote:
> > Radu Rendec a écrit :
> >> On 02/19/2020 at 10:11 AM Radu Rendec wrote:
> >>> On 02/18/2020 at 1:08 PM Christophe Leroy wrote:
> >>>> Le 18/02/2020 à 18:07, Radu Rendec a écrit :
> &
Hi Everyone,
The saved NIP seems to be broken inside machine_check_exception() on
MPC8378, running Linux 4.9.191. The value is 0x900 most of the times,
but I have seen other weird values.
I've been able to track down the entry code to head_32.S (vector 0x200),
but I'm not sure where/how the NIP
On Fri, 2021-06-11 at 08:02 +0200, Christophe Leroy wrote:
>Le 19/06/2019 à 14:57, Radu Rendec a écrit :
>> On Wed, 2019-06-19 at 10:36 +1000, Daniel Axtens wrote:
>>> Andreas Schwab <
>>> sch...@linux-m68k.org
>>>> writes:
>>>
>>&g
Hi Everyone,
I'm trying to set up my (virtual) environment to test an old bug in the
PPC32 ptrace() code. I came across a completely different problem,
which seems to make gdb pretty much unusable on PPC32. I'm not sure if
this is a real kernel bug or maybe something wrong with my
configuration.
On Tue, 2021-07-06 at 15:53 +0200, Christophe Leroy wrote:
>Le 06/07/2021 à 15:50, Radu Rendec a écrit :
>> On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
>>> Le 06/07/2021 à 13:56, Radu Rendec a écrit :
>>>> On Tue, 2021-07-06 at 12:43 +0200, Christop
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
> Le 04/07/2021 à 23:38, Radu Rendec a écrit :
> > I'm trying to set up my (virtual) environment to test an old bug in the
> > PPC32 ptrace() code. I came across a completely different problem,
> > which seems to
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
>Le 06/07/2021 à 13:56, Radu Rendec a écrit :
>> On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
>>> Le 04/07/2021 à 23:38, Radu Rendec a écrit :
>>>> I'm trying to set up my (virtual)
t; same place all the time.
> >
> > Instead of handling a special struct in addition to pt_regs, just
> > add those special registers to struct pt_regs.
> >
> > Reported-by: Radu Rendec
> > Signed-off-by: Christophe Leroy
> > Fixes: db297c3b07af (&qu
On Fri, 2021-06-11 at 10:37 -0400, Radu Rendec wrote:
>On Fri, 2021-06-11 at 08:02 +0200, Christophe Leroy wrote:
>>Le 19/06/2019 à 14:57, Radu Rendec a écrit :
>>> On Wed, 2019-06-19 at 10:36 +1000, Daniel Axtens wrote:
>>>> Andreas Schwab <
>&g
29 matches
Mail list logo
