On Jun 2, 2010, at 7:47 PM, Paul Mackerras wrote:
> On Wed, Jun 02, 2010 at 07:45:27AM -0500, Kumar Gala wrote:
>
>> Why do we need to have emu support for all of these instructions?
>
> Fair question. This arose in the context of the support for data
> breakpoint events in perf_events. Since
We use the wrong number arguments when invoking trace_kvm_stlb_inval,
and cause the following build error.
arch/powerpc/kvm/e500_tlb.c: In function 'kvmppc_e500_stlbe_invalidate':
arch/powerpc/kvm/e500_tlb.c:230: error: too many arguments to function
'trace_kvm_stlb_inval'
Signed-off-by: Kevin Ha
Hi Wayne,
> We also saw a variation of this problem last week and I have an alternative
> patch that I'd prefer over this one. I'll post the patch in a separate
> email.
Thanks. Can you get it into -stable too? As you can see users are hitting it.
Anton
Hi Anton,
We also saw a variation of this problem last week and I have an alternative
patch that I'd prefer over this one. I'll post the patch in a separate
email.
Thanks,
--
Wayne Boyer
IBM - Beaverton, Oregon
LTC S/W Development - eServerIO
(503) 578-5236, T/L 775-5236
On 06/02/2010 04:16
On Thu, 2010-06-03 at 11:10 +1000, Matt Evans wrote:
> Paul Mackerras wrote:
> > [snip]
> > The second alternative -- emulating the lwarx/stwcx and all the
> > instructions in between -- sounds complicated but turns out to be
> > pretty straightforward in fact, since the code for each instruction i
Paul Mackerras wrote:
> [snip]
> The second alternative -- emulating the lwarx/stwcx and all the
> instructions in between -- sounds complicated but turns out to be
> pretty straightforward in fact, since the code for each instruction is
> pretty small, easy to verify that it's correct, and has lit
On Wed, Jun 02, 2010 at 07:45:27AM -0500, Kumar Gala wrote:
> Why do we need to have emu support for all of these instructions?
Fair question. This arose in the context of the support for data
breakpoint events in perf_events. Since the data breakpoint facility
on our processors (DABR on server
Denis:
I have reviewed the change and agree to it. Thanks for catching that.
Carl Love
Denis Kirjanov
On Wed, Jun 02, 2010 at 04:59:16PM -0500, Kumar Gala wrote:
>
> On May 24, 2010, at 1:38 PM, Kumar Gala wrote:
>
> > From: Benjamin Herrenschmidt
> >
> > We can't just clear the user read permission in book3e pte, because
> > that will also clear supervisor read permission. This surely isn't
>
On May 24, 2010, at 1:38 PM, Kumar Gala wrote:
> From: Benjamin Herrenschmidt
>
> We can't just clear the user read permission in book3e pte, because
> that will also clear supervisor read permission. This surely isn't
> desired. Fix the problem by adding the supervisor read back.
>
> BenH:
On 06/02/2010 03:06 AM, Martyn Welch wrote:
I think that's a more fundamental change to CPM early debug than I can
handle right now.
Is IMMRBASE on your board at some address that has a low likelihood of
conflicting when treated as a kernel effective address?
It's at 0x0f00, is seems ok,
On Mon, May 31, 2010 at 09:59:13PM +0200, Andreas Schwab wrote:
> Instead of instantiating a whole thread_struct on the stack use only the
> required parts of it.
>
> Signed-off-by: Andreas Schwab
> Tested-by: Alexander Graf
> ---
> arch/powerpc/include/asm/kvm_fpu.h | 27 +
> a
The commit 061ca4ad still use the old style to refer to device
node, and cause the following compile error.
arch/powerpc/sysdev/fsl_msi.c: In function 'fsl_of_msi_probe':
arch/powerpc/sysdev/fsl_msi.c:350: error: 'struct of_device' has no member
named 'node'
Signed-off-by: Kevin Hao
---
arch/po
On Jun 2, 2010, at 6:29 AM, Paul Mackerras wrote:
> This extends the emulate_step() function to handle a large proportion
> of the Book I instructions implemented on current 64-bit server
> processors. The aim is to handle all the load and store instructions
> used in the kernel, plus all of the
On Fri, May 28, 2010 at 12:09:24PM +0530, K.Prasad wrote:
> Please find a new set of patches that have the following changes.
Thanks. There are a couple of minor things still remaining (dangling
put_cpu in arch_unregister_hw_breakpoint, plus I don't think reusing
current->thread.ptrace_bps
This extends the emulate_step() function to handle a large proportion
of the Book I instructions implemented on current 64-bit server
processors. The aim is to handle all the load and store instructions
used in the kernel, plus all of the instructions that appear between
l[wd]arx and st[wd]cx., so
Victor reported an oops during boot with 2.6.34 on a POWER6 JS22:
https://bugzilla.kernel.org/show_bug.cgi?id=16089
Checking ipr microcode levels
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x322d30312d31302c
...
Oops: Kernel access of bad area, sig
From: Wolfram Sang
Date: Wed, 19 May 2010 12:21:10 +0200
> - don't free bus->irq (obsoleted by ca816d98170942371535b3e862813b0aba9b7d90)
> - don't dispose irqs (should be done in of_mdiobus_register())
> - use fec-pointer consistently in transfer()
> - use resource_size()
> - cosmetic fixes
>
>
Scott Wood wrote:
> On 06/01/2010 08:43 AM, Martyn Welch wrote:
> diff --git a/arch/powerpc/kernel/head_32.S
> b/arch/powerpc/kernel/head_32.S
> index e025e89..861cace 100644
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -1194,12 +1194,13 @
Hi Linus !
Here's a reasonably urgent few bug fixes on top of -rc1. Grant OF stuff had
a few issues that broke pretty much all PowerMacs, so this fixes it, along
with a couple of misc fixes and a MAINTAINERS update.
Cheers,
Ben.
The following changes since commit aef4b9aaae1decc775778903922bd00
On Tue, 2010-06-01 at 23:26 -0700, Dmitry Torokhov wrote:
>
> FYI: i8042 core expects I8042_{KBD|AUX}_IRQ to be integers, however it
> is certainly fixable...
Let's not bother.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Grant patches added an of mach table to struct device_driver. However,
while he changed the macio device code to use that, he left the match
table pointer in struct macio_driver and didn't update drivers to use
the "new" one, thus breaking the probing.
This completes the change by moving all drive
> > It's crashing in macio_pci_add_devices.
>
> And snd-aoa is broken, too.
Right, all macio_driver's are. I have a fix, testing now.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc
23 matches
Mail list logo
