> > + /* Ignoring the return value from the unregister
> > +* call. A failed return value simply says there
> > +* was no registered event. Hence there will not
> > +* be any calls to process a switch event that
> > +* could cause a problem.
> > +*/
> > + spu_switch_event_
Please see my comments below.
-Roberta
On 30.04.08 13:35:12, Carl Love wrote:
[...]
> -int spu_sync_stop(void)
> +void spu_sync_stop(void)
> {
> unsigned long flags = 0;
> - int ret = spu_switch_event_unregister(&spu_active);
> - if (ret) {
> - printk(KERN_ERR "SPU_PR
On Thu, 2008-05-08 at 09:48 +0200, Jochen Roth wrote:
> >> Unable to handle kernel paging request for data at address
> >> 0xd04fe9a8
> >> Faulting instruction address: 0xd0330ad8
> >> cpu 0x0: Vector: 300 (Data Access) at [c0003c337680]
> >> pc: d0330ad8: .alloc_
Carl Love wrote:
> +void oprofile_add_value(unsigned long value, int cpu) {
> + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
Shouldn't it be
struct oprofile_cpu_buffer *cpu_buf = &per_cpu(cpu_buffer, cpu);
No, I don't think so. Take a look at the other functions in
driv
On Wed, 2008-05-07 at 18:54 +0200, Jochen Roth wrote:
> Carl,
>
> I applied your patch on Jeremy's latest kernel.org spufs tree.
>
> > +void oprofile_add_value(unsigned long value, int cpu) {
> > + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
>
> Shouldn't it be
> struct op
Carl,
I applied your patch on Jeremy's latest kernel.org spufs tree.
> +void oprofile_add_value(unsigned long value, int cpu) {
> + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
Shouldn't it be
struct oprofile_cpu_buffer *cpu_buf = &per_cpu(cpu_buffer, cpu);
At least my com
This is a reworked patch to fix the SPU data storage. Currently, the
SPU escape sequences and program counter data is being added directly
into the kernel buffer without holding the buffer_mutex lock. This
patch changes how the data is stored. A new function,
oprofile_add_value, is added into
