lkml.org 
[lkml]   [2009]   [Jul]   [3]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 03 Jul 2009 17:11:32 -0700
From"H. Peter Anvin" <>
SubjectRe: [Bug Fix]: Do 32-bit table calculations in pre-processor
Michael S. Zick wrote:
> On Fri July 3 2009, H. Peter Anvin wrote:
>> Michael S. Zick wrote:
>>>> The CPUID flags, in particular the pse flag.
>>>>
>>> I haven't touch anything that would have changed that -
>>> so this should be representative (the *&^*% datasheet says yes to pse also)
>>>
>> Actually, come to think of it, we don't generate PSE page tables
>> initially -- we only later go in and reclaim the page tables if we
>> switch to PSE (and $DEITY knows if we're doing it correctly...)
>>
>
> I am of that age range where senility has to be considered, but not this time:
>
> "Via C7-M Datasheet", May 2008 (supposed to be most recent) -
>
> page 22 - section 2.3.7 - Table 2-14 "CR4 Bits"
> "<5> PAE: Enables address extensions; C7-M:<r>"
> <quote>An "r" means that this bit is reserved. It appears as a 0 when read,
> and a GP exception is signaled if an attemp is made to write a 1 to this bit.</quote>
>
> Same document -
> page 16 - section 2.3.2 - Table 2-3 "CPUID Feature Flag Values (EAX=1)"
> <EDX:6> PAE: Physical address extensions; C7:<1>

Especially since I was talking about PSE and not PAE.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.



\
 
 \ /
  Last update: 2009-07-04 02:19    [from the cache]
©2003-2009