replacing synthesized tlb handlers with older ones

replacing synthesized tlb handlers with older ones

[Prasad Boddupalli]

Hi,

To embed some additional functionality in the tlb refill handler, I
replaced the synthesized refill handlers in 2.6.16 linux with those
from 2.6.6 (for example tlb-r4k.S under arch/mips/mm-32). Everything
seem ok when I bring up one CPU, but causes unrecoverable exceptions
in the kernel when I bring up multiple CPUs. I explored if that could
be because of unflushed icaches on other CPUs. but that doesn't seem
to be the case.

Have anyone run into similar problem ?

thank you,
Prasad.

Re: replacing synthesized tlb handlers with older ones

[Kevin D. Kissell]

The TLB refill handler behavior for 1 CPU is fundamentally
different than for SMP.  In the uniprocessor case, the page
table origin is implicit, whereas in SMP it needs to be indexed
by some per-CPU value, typically maintained in the Context
register.  Pre-synthesed kernels set up up so that the Context
value would be shifted left 23 bits, then right by 2 bits, to generate
an offset.  The newer system eliminates the right shift by ensuring
that the CPU index is stored in a pre-scaled form, and that bits
23 and 24 are zero.  So you can't just drop the old code into
the newer kernel, unless you also change the setup of Context.
A single CPU would work, because 0 == 0, otherwise...
Try nuking those right shifts.

            Regards,

            Kevin K.
 
----- Original Message ----- 
From: "Prasad Boddupalli" <bprasad@cs.arizona.edu>
To: <linux-mips@linux-mips.org>
Sent: Friday, June 02, 2006 8:39 PM
Subject: replacing synthesized tlb handlers with older ones


> Hi,
> 
> To embed some additional functionality in the tlb refill handler, I
> replaced the synthesized refill handlers in 2.6.16 linux with those
> from 2.6.6 (for example tlb-r4k.S under arch/mips/mm-32). Everything
> seem ok when I bring up one CPU, but causes unrecoverable exceptions
> in the kernel when I bring up multiple CPUs. I explored if that could
> be because of unflushed icaches on other CPUs. but that doesn't seem
> to be the case.
> 
> Have anyone run into similar problem ?
> 
> thank you,
> Prasad.
> 
> 

Re: replacing synthesized tlb handlers with older ones

[Kevin D. Kissell]

The TLB refill handler behavior for 1 CPU is fundamentally
different than for SMP.  In the uniprocessor case, the page
table origin is implicit, whereas in SMP it needs to be indexed
by some per-CPU value, typically maintained in the Context
register.  Pre-synthesed kernels set up up so that the Context
value would be shifted left 23 bits, then right by 2 bits, to generate
an offset.  The newer system eliminates the right shift by ensuring
that the CPU index is stored in a pre-scaled form, and that bits
23 and 24 are zero.  So you can't just drop the old code into
the newer kernel, unless you also change the setup of Context.
A single CPU would work, because 0 == 0, otherwise...
Try nuking those right shifts.

            Regards,

            Kevin K.
 
----- Original Message ----- 
From: "Prasad Boddupalli" <bprasad@cs.arizona.edu>
To: <linux-mips@linux-mips.org>
Sent: Friday, June 02, 2006 8:39 PM
Subject: replacing synthesized tlb handlers with older ones


> Hi,
> 
> To embed some additional functionality in the tlb refill handler, I
> replaced the synthesized refill handlers in 2.6.16 linux with those
> from 2.6.6 (for example tlb-r4k.S under arch/mips/mm-32). Everything
> seem ok when I bring up one CPU, but causes unrecoverable exceptions
> in the kernel when I bring up multiple CPUs. I explored if that could
> be because of unflushed icaches on other CPUs. but that doesn't seem
> to be the case.
> 
> Have anyone run into similar problem ?
> 
> thank you,
> Prasad.
> 
> 

Re: replacing synthesized tlb handlers with older ones

[Ralf Baechle]

On Fri, Jun 02, 2006 at 09:13:11PM +0200, Kevin D. Kissell wrote:

> The TLB refill handler behavior for 1 CPU is fundamentally
> different than for SMP.  In the uniprocessor case, the page
> table origin is implicit, whereas in SMP it needs to be indexed
> by some per-CPU value, typically maintained in the Context
> register.  Pre-synthesed kernels set up up so that the Context
> value would be shifted left 23 bits, then right by 2 bits, to generate
> an offset.  The newer system eliminates the right shift by ensuring
> that the CPU index is stored in a pre-scaled form, and that bits
> 23 and 24 are zero.  So you can't just drop the old code into
> the newer kernel, unless you also change the setup of Context.
> A single CPU would work, because 0 == 0, otherwise...
> Try nuking those right shifts.

And beyond that, the old ones hardly made any reasonable attempt at
getting TLB hazard handling right, so depending on hardware they will
blow up.

  Ralf