On Fri, 2008-05-16 at 16:22 +0200, Arnd Bergmann wrote:
> On Thursday 15 May 2008, Carl Love wrote:
> > On Thu, 2008-05-15 at 17:39 +0200, Arnd Bergmann wrote:
> > >
> > > I noticed now that you are indexing arrays by SPU number. This is not
> > > a good idea, because you make assumptions about t
On Thursday 15 May 2008, Carl Love wrote:
> On Thu, 2008-05-15 at 17:39 +0200, Arnd Bergmann wrote:
> >
> > I noticed now that you are indexing arrays by SPU number. This is not
> > a good idea, because you make assumptions about the system that may
> > not be true. Better pass around 'struct spu'
On Thu, 2008-05-15 at 17:39 +0200, Arnd Bergmann wrote:
> On Thursday 01 May 2008, Carl Love wrote:
>
> > Finally, this patch backs out the changes previously added to the
> > oprofile generic code for handling the architecture specific
> > ops.sync_start and ops.sync_stop that allowed the arch
On Thursday 01 May 2008, Carl Love wrote:
> Finally, this patch backs out the changes previously added to the
> oprofile generic code for handling the architecture specific
> ops.sync_start and ops.sync_stop that allowed the architecture
> to skip the per CPU buffer creation.
Thanks for your pa
> > + /* 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
Phil,
When you have a chance, could you please take a look at the
arch-independent pieces of the OProfile kernel driver that this patch
touches? In short, this patch fixes a bug that I was responsible for in
my original OProfile-Cell SPE port (argh! :-[ ) where I was
improperly adding events
Carl Love wrote:
Sorry, looks like my mailer mangled the file.
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
Sorry, looks like my mailer mangled the file.
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
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
14 matches
Mail list logo
