Benjamin Herrenschmidt wrote:
Hi Mahesh !
Hi Benjamin,
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @addr: address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kern
I'm working on an mpc8548 based board and recently I've encountered a
problem, whereupon kernel crashed each time module loading is attempted. I
traced the problem to the fact, that vmalloc_exec was setting incorrect
page attributes on allocated pages. This, in turn, happened because I
specified "L
On Thu, 2009-12-10 at 20:45 -0600, Kumar Gala wrote:
> What do we do in EDM mode? We need a flag somewhere to determine if
> HW supports conveying DBCR0[EDM] and if it does which of the ptrace
> calls fails?
I really don't have a good answer to this. I'm open to any and all
advice.
Shaggy
--
On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
>
> > These patches implement an extention to the ptrace interface proposed by
> > Thiago Bauermann and the the PowerPC gdb team.
> >
> > GDB intends to support the following hardware debug fe
On Fri, 2009-12-11 at 14:26 +1100, David Gibson wrote:
> On Thu, Dec 10, 2009 at 01:57:27PM -0200, Dave Kleikamp wrote:
> > powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
> >
> > From: Torez Smith
> >
> > This patch defines context switch and trap related functionality
>
On Thu, 2009-12-10 at 20:50 -0600, Kumar Gala wrote:
> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
>
> > powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
> >
> > From: Torez Smith
> >
> > This patch defines context switch and trap related functionality
> > for BookE
On Fri, 2009-12-11 at 11:53 +1100, David Gibson wrote:
> On Thu, Dec 10, 2009 at 01:57:21PM -0200, Dave Kleikamp wrote:
> > powerpc: Add definitions for Debug Registers on BookE Platforms
> >
> > From: Torez Smith
> >
> > This patch adds additional definitions for BookE Debug Registers
> > to th
On Thu, 2009-12-10 at 12:07 -0500, Josh Boyer wrote:
> On Thu, Dec 10, 2009 at 01:57:21PM -0200, Dave Kleikamp wrote:
> >+/*
> >+ * The stored value of the DBSR register will be the value at the
> >+ * last debug interrupt. This register can only be read from the
> >+ * user (will
On Mon, 2010-01-18 at 07:32 -0500, Josh Boyer wrote:
> You missed my defconfig updates. I sent you a pull request 2 weeks
> ago.
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079309.html
>
> Those are still sitting in that tree on that branch if someone wanted
> to pull
> them
powerpc: Add definitions for Debug Registers on BookE Platforms
From: Torez Smith
This patch adds additional definitions for BookE Debug Registers
to the reg_booke.h header file.
Signed-off-by: Torez Smith
Signed-off-by: Dave Kleikamp
Acked-by: David Gibson
Cc: Benjamin Herrenschmidt
Cc: J
powerpc: Add support for BookE Debug Reg. traps, exceptions and ptrace
From: Torez Smith
This patch defines context switch and trap related functionality
for BookE specific Debug Registers. It adds support to ptrace()
for setting and getting BookE related Debug Registers
Signed-off-by: Torez Sm
powerpc: Extended ptrace interface
From: Torez Smith
Add a new extended ptrace interface so that user-space has a single
interface for powerpc, without having to know the specific layout
of the debug registers.
Implement:
PPC_PTRACE_GETHWDEBUGINFO
PPC_PTRACE_SETHWDEBUG
PPC_PTRACE_DELHWDEBUG
Si
These patches implement an extention to the ptrace interface proposed by
Thiago Bauermann and the the PowerPC gdb team.
This is a resubmission of the patches I first sent on December 9th.
Sorry for the delay. I have addressed most of the comments, and I'll
follow up on the others.
These patches
Hello,
I finally got the dtb working for the Kernel 2.6.32.2. I went to an
old folder backup that I had in which I found some files used by LTIB
for the Kernel configuration and restore them (including .config file).
Then, I removed the /localbus and /pci references from my dtb file
because I a
On Jan 18, 2010, at 10:20 AM, Martyn Welch wrote:
> Hi,
>
> I'm currently adding support for a GE board based on the Freescale
> P2020. This board has a cascaded interrupt controller and GPIO which
> should be compatible with drivers currently provided for the MPC8641D
> based boards that are al
On Thu, Dec 17, 2009 at 8:57 AM, Sylvain Lamontagne
wrote:
> Hi all,
> I would like to be able to set a baud rate of 460800 for modem that we are
> testing. With the actual prescaler of 32 and a IPB frequency of 84MHz
> I got a 5.1% error (437500) vs a 0.9% error (456522) if I could use the
> pres
On Fri, Jan 15, 2010 at 2:23 AM, Michal Simek wrote:
> Benjamin Herrenschmidt wrote:
>> On Wed, 2010-01-13 at 16:23 +0100, Michal Simek wrote:
>>> Thanks for this early discuss. I would like to hear your opinion and then
>>> I will choose solution how to add our pci support to mainline.
>
> I will
On Wed, Jan 13, 2010 at 7:07 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2010-01-13 at 16:23 +0100, Michal Simek wrote:
>
>> The main problems are:
>> ppc use ppc_md struct which we don't have it on Microblaze.
>> xilinx-pci driver uses exclude_device function. This function is used in
>> indirect
On Wed, Jan 13, 2010 at 8:23 AM, Michal Simek
wrote:
> Hi guys,
>
> We (John and partially I) did initial support for pci on Microblaze.
> It is based on powerpc files and almost everything is the same.
> There are some small differences which could be easily removed that's why I
> think that will
Hi,
I'm currently adding support for a GE board based on the Freescale
P2020. This board has a cascaded interrupt controller and GPIO which
should be compatible with drivers currently provided for the MPC8641D
based boards that are already in the kernel.
At the moment the drivers (in gef_gpio.c a
On Wed, Dec 16, 2009 at 01:58:09AM +0300, Anton Vorontsov wrote:
> MPC85xx chips report the wrong value in feature reporting register,
> and that causes the following oops:
>
> Unable to handle kernel paging request for data at address 0x0c00
> Faulting instruction address: 0xc0019294
> Oop
From: Jiajun Wu
commit 7583605b6d29f1f7f6fc505b883328089f3485ad ("ucc_geth: Fix empty
TX queue processing") fixed empty TX queue mishandling, but didn't
account another corner case: when TX queue becomes full.
Without this patch the driver will stop transmiting when TX queue
becomes full since '
A timer has been added into my system, and it is used to generate
continuous interrupt every 1 ms.
This hw is register by request_irq(19, handler_1ms)
Howeve I found that , it is longer than 1 ms between two interrupts,
for I used get_cycles everytime we entered
do_irq :
if(irq==19)
{
Virtio consoles can be hotplugged, so hvc_alloc gets called from
multiple sites: from the initial probe() routine as well as later on
from workqueue handlers which aren't __devinit code.
So, drop the __devinit annotation for hvc_alloc.
Signed-off-by: Amit Shah
Cc: linuxppc-...@ozlabs.org
---
dr
From: Rusty Russell
This is nicer for modern R/O protection. And noone needs it non-const, so
constify the callers as well.
Signed-off-by: Rusty Russell
Signed-off-by: Amit Shah
To: Christian Borntraeger
Cc: linuxppc-...@ozlabs.org
---
drivers/char/hvc_beat.c |2 +-
drivers/char/h
On Mon, Jan 18, 2010 at 05:45:48PM +1100, Benjamin Herrenschmidt wrote:
>Hi Linus !
>
>A tad late due to me slacking and leaving the patches take dust in
>patchwork for a bit too long, but here are a few bug fixes for powerpc
>and a bunch of defconfig freshen ups for some of our embedded platforms.
Johnny Hung wrote on 18/01/2010 09:26:26:
>
Please don't top post.
> Yes, umount / reboot command doesn't hang after first boot + wait for
> 20 minutes. The jffs2_gcd_mtdx will re-erase empty blocks but how do I
> know it is finished?
You don't or just monitor jffs2_gcd_mtdx until it is finished
Greetings.
I've got a rather weird problem and hope that somebody may have encountered
it before.
I've got an MPC8548 based board which was not supported by the
u-boot/kernel, but was quite similar to other AMC boards of this sort. I
patched up the kernel and stress-tested the board quite extensi
Yes, umount / reboot command doesn't hang after first boot + wait for
20 minutes. The jffs2_gcd_mtdx will re-erase empty blocks but how do I
know it is finished?
BTW, why jffs2_gcd_mtd need to re-erase empty blocks and it will cause
some command cannot work if erase block is necessary. I mean many
29 matches
Mail list logo