On 25/06/11 17:33, Andreas Schwab wrote:
> Matt Evans writes:
>
>> +stdur1, -128(r1); \
>
>> +addir5, r1, 128+BPF_PPC_STACK_BASIC+(2*8); \
>
>> +addir1, r1, 128;\
>
>> +
On 25/06/11 11:58, Ben Hutchings wrote:
> On Fri, 2011-06-24 at 16:02 +1000, Matt Evans wrote:
> [...]
>> +case BPF_S_ALU_ADD_K: /* A += K; */
>> +if (!K)
>> +break;
>> +if (K < 32768)
>> +PP
On Mon, Jul 11, 2011 at 10:39:35AM +0800, Tiejun Chen wrote:
> When enable CONFIG_PREEMPT we will trigger the following call trace:
>
> BUG: scheduling while atomic: swapper/1/0x1000
> ...
>
> krpobe always goes through the following path:
>
> program_check_exception()
> |
>
On POWER6 and POWER7 if the input operand to an instruction is a
denormalised single precision binary floating we can take a
denormalisation exception where it's expected that the hypervisor (HV=1)
will fix up the inputs before the instruction is run.
This adds code to handle this denormalisation
When kprobe these operations such as store-and-update-word for SP(r1),
stwu r1, -A(r1)
The program exception is triggered, and PPC always allocate an exception frame
as shown as the follows:
old r1 --
...
nip
gpr[2] ~ gpr[31]
gpr[1] <- old r1 i
v1 -> v2: when allocate pgirq_ctx, use 'hw_cpu' to identify cpu ID in
exc_lvl_early_init().
BTW, I already validated these patches on fsl mpc8536 by kprobe do_fork() and
show_interrupts().
Note this bug I fixed is from another email thread,
"[BUG?]3.0-rc4+ftrace+kprobe:
set kprobe at instruct
When enable CONFIG_PREEMPT we will trigger the following call trace:
BUG: scheduling while atomic: swapper/1/0x1000
...
krpobe always goes through the following path:
program_check_exception()
|
+ notify_die(DIE_BPT, "breakpoint",...)
|
+ kprob
Change the string to check for CAMP mode boot on MPC85xx (eg. P2020) to match
the one in the corresponding dts files (p2020rdb_camp_core{0,1}.dts).
Without this fix the mpic is configured as in the SMP boot mode, which causes
the first core to report a protected source interrupt error for devices
