lkml.org 
[lkml]   [2002]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CPU/cache detection wrong
On Tue, 1 Oct 2002, Dave Jones wrote:

> > > Some of the tualatins have an errata which makes L2 cache sizing
> > > impossible. They actually report they have 0K L2 cache. By checking
> > > the CPU model, we can guess we have at least 256K (which is where Linux
> > > got that number from in your case). But this however means the 512K
> > > models will report as 256K too.
> > > To work around it, boot with cachesize=512 and all will be good.
> >
> > Strange -- why not to default to 256K and override it with the value
> > obtained from a cache descriptor if != 0, then?
>
> Because the cache descriptor IS zero. So we default to 256K.

You wrote "some of", so I suppose others are OK. I meant those others.
Anyway -- is it a new problem? I can't see it documented in the current
P3 spec update. That's weird -- Intel might hesitate documenting
weirdnesses of their chips, however they tend to include such simple and
obvious errata in the update.

The spec actually states the L2 descriptor for the P3 may be as follows:

- 0x43 -- 512kB, unified,

- 0x82 -- 256kB, 8-way set associative,

- 0x83 -- 512kB, 8-way set associative.

The last descriptor is omitted from the list of known types in cache_table
in 2.4.20-pre8 -- could it be the culprit?

Maciej

--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [from the cache]
©2003-2011 Jasper Spaans