a quick question regarding CONFIG_MIPS_UNCACHED..

a quick question regarding CONFIG_MIPS_UNCACHED..

[atul srivastava]

Hello,

Is it sufficient to set "CONFIG_MIPS_UNCACHED" in order to track 
a
possible cache related problem otherwise hard to debug.
in so many places the functions to operate on caches are called
directly..don't they should be placed under
"#ifdef CONFIg_MIPS_UNCACHED" , if not technically then at least
for consistent coding.

secondly if once i have gone for UNCACHED operation then 
dump_tlb_all
should show the "page cheency attribute" for all entries as 
"UNCACHED" anywhere in whole address space..

in my case this attribute for some entries in TLB is still 
showing
"Cacheable, noncoherent, write-through, no write allocate" ..how 
this is possible..

following is the relevant code:--

#ifdef CONFIG_MIPS_UNCACHED
         change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
#else
         change_cp0_config(CONF_CM_CMASK, 
CONF_CM_CACHABLE_NONCOHERENT);
#endif

Best Regards,
Atul

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Maciej W. Rozycki]

On 27 Nov 2002, atul srivastava wrote:

> following is the relevant code:--
> 
> #ifdef CONFIG_MIPS_UNCACHED
>          change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED);
> #else
>          change_cp0_config(CONF_CM_CMASK, 
> CONF_CM_CACHABLE_NONCOHERENT);
> #endif

 You are looking at obsolete code -- unless you have specific conditions
to use an explicit caching attribute for KSEG0, you should set it like the
rest of the code does it, i.e.:

change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT);

To avoid surprises here and elsewhere, you should make sure
CONFIG_NONCOHERENT_IO is set appropriately, too.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Ralf Baechle]

On Thu, Nov 28, 2002 at 04:51:57PM +0100, Maciej W. Rozycki wrote:

>  You are looking at obsolete code -- unless you have specific conditions
> to use an explicit caching attribute for KSEG0, you should set it like the
> rest of the code does it, i.e.:
> 
> change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT);
> 
> To avoid surprises here and elsewhere, you should make sure
> CONFIG_NONCOHERENT_IO is set appropriately, too.

We've talked about this before - the specification of the ll/sc
instructions says they only work ok on cached memory.  In the real world
they seem to work also in uncached memory but I'd not bet the farm on
that, too many implementations out there, too many chances for subtle
bugs.

  Ralf

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Maciej W. Rozycki]

On Thu, 28 Nov 2002, Ralf Baechle wrote:

> We've talked about this before - the specification of the ll/sc
> instructions says they only work ok on cached memory.  In the real world
> they seem to work also in uncached memory but I'd not bet the farm on
> that, too many implementations out there, too many chances for subtle
> bugs.

 Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
CONFIG_CPU_HAS_LLSC=n.  I suppose there is some interest in the option, so
the latter is preferable.  That would imply moving the option into the CPU
configuration section as now it's set very late, long after
CONFIG_CPU_HAS_LLSC is set.  Or it could be set up the other way, i.e. the
option would only become available if CONFIG_CPU_HAS_LLSC had been set to
n.  There would be no need to move it then. 

 What do you think? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Ralf Baechle]

On Fri, Nov 29, 2002 at 12:56:10PM +0100, Maciej W. Rozycki wrote:

> > We've talked about this before - the specification of the ll/sc
> > instructions says they only work ok on cached memory.  In the real world
> > they seem to work also in uncached memory but I'd not bet the farm on
> > that, too many implementations out there, too many chances for subtle
> > bugs.
> 
>  Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
> CONFIG_CPU_HAS_LLSC=n.  I suppose there is some interest in the option, so
> the latter is preferable.  That would imply moving the option into the CPU
> configuration section as now it's set very late, long after
> CONFIG_CPU_HAS_LLSC is set.  Or it could be set up the other way, i.e. the
> option would only become available if CONFIG_CPU_HAS_LLSC had been set to
> n.  There would be no need to move it then. 
> 
>  What do you think? 

I had the same thought.  So far there are the following groups of people
using this option:

  - Hardware people using it so the the entire program is becoming visible
    externally.

    Becoming obsoleted by more advanced, less intrusive hardware debugging
    methods.

  - Software people kluding around bugs in their software.

    Don't expect me to support this.  Note with a line of code.

  - For testing if the cache code is actually working.

    Will only be useful to show big fat bugs.  For the more subtle bugs
    there is no way at all around understanding the entire cache managment
    thing including all subtilities.  Actually a good reason to not support
    this option either.

It's been my observation that hardly any user is aware of these consquences
nor is the Linux code making a good attempt at complying with all the
additional restrictions of running uncached.  So in my oppinion
CONFIG_MIPS_UNCACHED should go.  But I don't feel very strong about it so
I'm going to wait for a few days so others have a chance to raise their
voice.

  Ralf

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Maciej W. Rozycki]

On Fri, 29 Nov 2002, Ralf Baechle wrote:

> It's been my observation that hardly any user is aware of these consquences
> nor is the Linux code making a good attempt at complying with all the
> additional restrictions of running uncached.  So in my oppinion
> CONFIG_MIPS_UNCACHED should go.  But I don't feel very strong about it so
> I'm going to wait for a few days so others have a chance to raise their
> voice.

 I completely agree with your points and I'm not fond of this option,
either.  I had a need to run uncached to debug a problem once and even
then it was on the R3k, so I had to set up things differently from what
that option does anyway.  I can't recall the details of the problem, but
coding hooks for an uncached setup took me maybe half an hour, so I don't
think that is a problem for anyone who really needs it.

 BTW, how do you know that ll/sc happens to work for uncached operation on
some processors?  Maybe it simply fails, but the result is subtle enough
not to be observed easily.  A failure may be masked by other factors, e.g. 
for the UP operation, there is normally no way for two parallel requests
for a spinlock to happen and an exception resets the LLbit regardless of
the caching attribute of the area involved.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Ralf Baechle]

On Fri, Nov 29, 2002 at 02:03:00PM +0100, Maciej W. Rozycki wrote:

>  BTW, how do you know that ll/sc happens to work for uncached operation on
> some processors?  Maybe it simply fails, but the result is subtle enough
> not to be observed easily.  A failure may be masked by other factors, e.g. 
> for the UP operation, there is normally no way for two parallel requests
> for a spinlock to happen and an exception resets the LLbit regardless of
> the caching attribute of the area involved.

That's a consequence of the simplemost way to implement ll/sc in hardware.
ll puts the physicall address of the the memory reference into c0_lladdr
and sets the ll-bit.  eret clears the ll-bit and finally sc fails if the
ll-bit is cleared.  That's the simplest implementation for a non-coherent
uniprocessor, there is not much more needed that a flip-flop and due to
every designers desire for simplicity a different implementation seem
unlikely.  Btw, c0_lladdr is just a useless gadget here.

It's different for coherent processors, those actually need to snoop on
the bus interface.  On those the simplest implementation is ll generates
a cache line in exclusive state; sc then fails if either the ll-bit has
been cleared; the snooping logic clears the ll-bit if the cache-line's
state changes or an eret is executed.  So the mechanism fails without
caches.

  Ralf

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Maciej W. Rozycki]

On Fri, 29 Nov 2002, Ralf Baechle wrote:

> That's a consequence of the simplemost way to implement ll/sc in hardware.
> ll puts the physicall address of the the memory reference into c0_lladdr
> and sets the ll-bit.  eret clears the ll-bit and finally sc fails if the
> ll-bit is cleared.  That's the simplest implementation for a non-coherent
> uniprocessor, there is not much more needed that a flip-flop and due to
> every designers desire for simplicity a different implementation seem
> unlikely.  Btw, c0_lladdr is just a useless gadget here.

 Hmm, MIPS doesn't support external invalidation requests for non-coherent
areas, so eret/rfe appears to be the only way to reset the LLbit.  So we
may simply make the option depend on CONFIG_NONCOHERENT_IO=y.  It would
simplify the CML hassle, too.

> It's different for coherent processors, those actually need to snoop on
> the bus interface.  On those the simplest implementation is ll generates
> a cache line in exclusive state; sc then fails if either the ll-bit has
> been cleared; the snooping logic clears the ll-bit if the cache-line's
> state changes or an eret is executed.  So the mechanism fails without
> caches.

 Oh, I think a comparator using CP0.LLAddr for any bus cycles wouldn't be
much more complicated if at all.  But it would then spuriously fail for
noncoherent areas, so the actual implementation is better.

 So how about the following patch?

 And yes, the Carsten's argument is valid, too.  The option need not
necessarily be used to debug Linux -- it may be used to debug hardware or
to run on an incomplete implementation.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-2.4.20-pre6-20021129-mips-uncached-0
--- linux/arch/mips/config-shared.in.macro	Fri Nov 22 13:28:35 2002
+++ linux/arch/mips/config-shared.in	Fri Nov 29 14:13:53 2002
@@ -836,9 +836,7 @@ if [ "$CONFIG_AU1000_UART" = "y" -o "$CO
 fi
 bool 'Enable run-time debugging' CONFIG_DEBUG
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
-if [ "$CONFIG_SMP" != "y" ]; then
-   bool 'Run uncached' CONFIG_MIPS_UNCACHED
-fi
+dep_bool 'Run uncached' CONFIG_MIPS_UNCACHED $CONFIG_NONCOHERENT_IO
 endmenu
 
 source lib/Config.in

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

[Carsten Langgaard]

Ralf Baechle wrote:

> On Fri, Nov 29, 2002 at 12:56:10PM +0100, Maciej W. Rozycki wrote:
>
> > > We've talked about this before - the specification of the ll/sc
> > > instructions says they only work ok on cached memory.  In the real world
> > > they seem to work also in uncached memory but I'd not bet the farm on
> > > that, too many implementations out there, too many chances for subtle
> > > bugs.
> >
> >  Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
> > CONFIG_CPU_HAS_LLSC=n.  I suppose there is some interest in the option, so
> > the latter is preferable.  That would imply moving the option into the CPU
> > configuration section as now it's set very late, long after
> > CONFIG_CPU_HAS_LLSC is set.  Or it could be set up the other way, i.e. the
> > option would only become available if CONFIG_CPU_HAS_LLSC had been set to
> > n.  There would be no need to move it then.
> >
> >  What do you think?
>
> I had the same thought.  So far there are the following groups of people
> using this option:
>
>   - Hardware people using it so the the entire program is becoming visible
>     externally.
>
>     Becoming obsoleted by more advanced, less intrusive hardware debugging
>     methods.
>
>   - Software people kluding around bugs in their software.
>
>     Don't expect me to support this.  Note with a line of code.
>
>   - For testing if the cache code is actually working.
>
>     Will only be useful to show big fat bugs.  For the more subtle bugs
>     there is no way at all around understanding the entire cache managment
>     thing including all subtilities.  Actually a good reason to not support
>     this option either.
>
> It's been my observation that hardly any user is aware of these consquences
> nor is the Linux code making a good attempt at complying with all the
> additional restrictions of running uncached.  So in my oppinion
> CONFIG_MIPS_UNCACHED should go.  But I don't feel very strong about it so
> I'm going to wait for a few days so others have a chance to raise their
> voice.
>

I have used this option a lot, it has been very useful in hardware (CPU)
debugging.


>
>   Ralf

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com