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 +
